What role should story points play in sprint planning?

Question

I am the scrum master of a team that estimates its user stories using story points. The development team consists of backend and frontend developers.

Currently, what I am doing during every sprint planning, is averaging the individual velocity for the past sprints and using that as a guideline for the stories which should be part of the planned sprint. I'm doing this because a frontend developer cannot do the backend developers' work.

Using the team's velocity as a guideline does not seem right because then the backend developers might end up with more work than the frontend developers or the other way around.

Am I making proper use of the story points?

Answer 1

Individuals don't have velocity, teams have velocity.

Even if you have two roles in the team (backend and frontend), with some people unable to do other people's work, it's still the team as a whole that delivers work. Can you deliver only the backend to the user, with no frontend? Or the other way? No.

So the sum of all the story points delivered in a sprint will be the team velocity, and it's something you can use to forecast future work or use as a reference to know how much work to pull in a sprint. Most of the times you also have backend and front end work on stories, and even if some sprint one effort leans towards backend or frontend, on the long run it tends to balance. So you need to use the team velocity.

Now, about using the velocity, the question is how you use it. I've sometimes seen people say "Hey team, we averaged 100 SPs these last 3 sprints, so let's target 100 SPs this sprint also". That sounds good, but then they shove stuff into the sprint and stop when they hit 100 SPs. This isn't right.

That number should be a guide. You properly do your planning and then ask the team how confident they are in reaching the sprint goal with the work they have planned. You can then use the previous velocity to get a better understanding of what is going on. For example, if the team now pulls only 50 SPs or tries for 150 SPs, then you ask what is different, and why, and plan accordingly. You don't just shove 100 SPs on the team's throat.

So don't use "individual velocity". If people end up with less or more work then you can cross that bridge when you get there. For example, you could pull more work if that doesn't create negative effects on the current sprint, people can help others with their work if they become available sooner, they can pair program and spread the knowledge trying to become more cross-functional, etc. In Scrum, teams deliver software, not individuals.

Answer 2

Using the team's velocity as a guideline does not seem right because then the backend developers might end up with more work than the frontend developers or the other way around.

What a lot of teams will do in this situation is to estimate in story points as a team, but then sanity check that they aren't overloading one particular specialism in the team.

For example, I have worked with teams that first estimate the stories in story points. They then add stories to the sprint backlog using their team velocity as a guide. Next they break the stories down into technical tasks (this is the first time they differentiate between front-end and back-end work).

Finally, they look at the tasks in the sprint and check to make sure one particular speciality is not overloaded. The Scrum Master might say something like this:

"OK, we have 25 story points in the sprint backlog, which corresponds to our team velocity. Unfortunately if we look at the tasks we can see there looks like more front-end work than back-end work. How about we take this story out and replace it with this other story from the backlog which is heavier in back-end work? Does that feel right?"

Answer 3

The team shouldn't have to rely on points to decide how much work they should have in the sprint. Let the team use their own judgement about what stories they can take into a sprint and then track velocity retrospectively as a measure of the team's productivity. Velocity should be for the whole team's effort rather than individuals.

If the team don't feel able to forecast the work they can do without knowing their velocity that may just indicate that they don't understand the work well enough, or possibly that the sprint is too long.

Answer 4

Most computer applications these days have a "front end" and a corresponding "back end" that are tightly coupled. Therefore, you need to regard both sections at the same time. It helps to have developers who are experienced with both sides.

The total functionality of the system also builds upon itself. There's only so much discretion that you can meaningfully have, and "user stories" (or "story points" derived from them) might not adequately consider – or perhaps, consider at all – the technicalities of the system that is to implement them. You need to understand the architecture of the system that you're developing, so that pieces can be completed and put in place in the most effective sequence.