Sprint velocity, what is it good for?

Software development teams doing scrum try in one way, or the other to measure their velocity.

Velocity is usually measured as the number of completed stories or as the number of completed story points in a sprint. The first one is pretty straight forward, the second one is a bit more elusive, so I am going to explain it further in the next section. Especially, since I’ve seen teams spend quite some effort trying to get the story points right!

The mythical story points

What do those “points” assigned in a story really mean? Usually, people use them to mean one of two things “effort” or “complexity”. Developers also tend to calibrate their estimation based on how “uncertain” they feel, but let’s leave the aspect uncertainty on the side for now.

Effort is usually a proxy on how much work the developers will have to put to complete the story.

Complexity is about how intrinsically complex a task is.

Complexity depends on the task. Effort depends on the task and on the team.

I see the following distinction between “effort” and “complexity”. Given a team that is continuously improving (they learn how to use their tools better, they learn how to work better together etc), the amount of effort they need to put to complete a task goes down, whereas the complexity of the task remains the same.

Consequently, teams that measure “effort” points will see their velocity remain roughly stable over time. Because as they learn to develop faster, they will assign fewer “effort” points to stories as would for similar stories in the past.

On the other hand, teams that measure “complexity” points will see their velocity increase over time. Because they will tend to estimate similar stories with similar story points across sprints. So, as their productivity increases the amount of “complexity” points they can conclude in a sprint also goes up.

Velocity

Either by counting stories or story point, the goal is to sum all of them up at the end of sprint and come up with the Velocity of the team. You can look back into the past velocity to see how well the team was doing and can use past velocity to forecast future performance.

Why do we need Velocity?

Sprint planning

One common use case for velocity is to support planning the next sprint. But why? Why is it so important in the beginning of a sprint to come up with a number that may or may not be close to reality in the end of the sprint? Or to put in another way, in your organisation, what is the impact of not successfully completing as many story points as agreed at the beginning of the sprint. And here, I am asking about the real business impact.

In my experience from large organisations, business impact has more to do with satisfying cross-team dependencies. For example, we need to complete “X” in this sprint to unblock some other team. Or with planning longer than just a sprint. For example, the organisation wants to release feature “Y” in 3 months time and all teams involved in that feature need to be ready by then. The first example has more to do with proper prioritisation, and the second requires forecasting velocity much further than just the next sprint.

Long term planning

When talking about projects and products developed by multiple teams and spend many years in active development, you need to be able to plan many months ahead, and to be able to communicate early in advance when a milestone is likely to be missed. The earlier you can identify that a milestone may be missed the easier (and cheaper) it is to take corrective action.

Using story points trying to predict where you are going to be doing 3 months into the future (about 6 sprints given the typical 2-week sprints) is just not practical. It is not only the amount of stories that need to be estimated, you also need to keep re-estimating as the new information becomes available, and the plan changes. Product Owners and Business Analysts must maintain a healthy backlog of user stories for the next 3 months. I use the word maintain because a backlog requires constant maintenance to remain useful. But additionally to their effort, you need also need to the time of the developers to move from a groomed story to an estimated story and that is a trade off. Because the time developers spend estimating stories is time they could have spent delivering stories instead.

In another blog post, I am going to talk about how statistics can help quantify your confidence in achieving longer term milestones.

Be pragmatic

When talking about estimations, there are some times an ideological element involved. For example, people who like Kanban tend to prefer counting stories, people who like Scrum tend to prefer story points etc. But based on the use case there are objective measures you can use to evaluate your options.

One measure it the cost needed to implement the system. Counting stories takes less effort than estimating and counting story points. Effort that is taken away from actual delivery.

Another measure is the accuracy of the system. If you are measuring velocity for the purpose of forecasting, then measure how close the projection comes to reality. For example take your velocity based on completed stories in the last sprint and make a forecast for the next two sprints, you can measure your velocity in “effort” points and in “complexity” points. After a month, whichever forecast comes closer to reality that’s the one that you should be using!

You can also run this experiment with past data if you have them available.

Conclusion

What to measure as velocity depends on three factors:

• The “Why” you measure. You intend to use the results to plan the next 2 weeks or the next 3 months?
• The accuracy of the measurement. Measure how close estimations fall to reality and use the most accurate measure for your team.
• The cost of the measurement. Measuring story points takes a lot more effort than counting stories.

I hope I gave some clarity to the different aspects of the topic so that teams can take more informed decision in choosing what to do. I believe this can save some teams a lot of time and increase the quality of their forecasting.

• Agile
• Statistics