Agile velocity vs capacity
There is a lot of confusion and uncertainty around velocity and capacity in an agile context. This is especially the case when talking about sprint planning in Scrum. In this article I will explain the difference between velocity and capacity, and explain how you can use each one, and how not to use them. So there hopefully won’t be any more confusion on the topic of velocity vs capacity.
What is velocity?
Velocity is possibly the most commonly used and discussed metrics in the agile community. While it was originally invented by Ron Jeffries as part of Extreme Programming (as immortalised in Kent Beck’s famous book), it has become more widely used in a Scrum context these days.
Velocity is simply the total of all the story point estimates of all the user stories (or other backlog items that have had story point estimates assigned to them) that were completed in a sprint.
Some important points:
- this total only includes the story point estimates of things that were 100% completed (according to the Definition of Done) in the sprint – 99% is not 100% and so doesn’t count
- it includes all things that were completed in that sprint, regardless of when they were created or how long they took – if you created a story in sprint 1, pulled it into the sprint backlog of sprint 2, and finished it in sprint 4, the points are added to the velocity of sprint 4, and nowhere else.
There are still some debates going on around velocity, such as should defects be assigned story points, should production issues get story points, and so on. I won’t go into those now (though you can read up what I think about estimating defects here).
How is velocity used?
Velocity can be used properly in only one way. Most of the other ways that people use velocity (especially as a form of measuring “productivity”) are a form of abuse.
As an input to capacity planning
We haven’t got to capacity yet – we will soon. So spoiler alert: velocity can play a part in discussing capacity (though they are not at all the same).
The only other possible use I can think of for velocity is for a target metric for Kaizen / Continuous Improvement. That is, the team wants to try and experiment to increase their velocity. The problem with that is that velocity isn’t necessarily a good metric to try and improve – Throughput and Cycle Time are usually better.
But that’s another topic – let’s go on to capacity.
What is capacity?
Capacity is how much work a team feels they can bring in to a sprint. This can be measured in different ways. It could be in terms of story points, or it could be in terms of number of stories, or just gut feel, or some other method.
It is vital to remember that this metric, like velocity or any other metrics, should be assessed and discussed at a team level, never at an individual level. You should never be calculating story points or velocity or capacity at an individual developer level. That defeats the entire purpose of Scrum’s focus on team accountabilities.
So while teams can use different methods for talking about capacity, teams often use story points, which is where velocity enters the picture.
Velocity vs capacity in agile
Velocity is often used to calculate capacity – i.e. if a team’s velocity is 20, then the team might decide to pull 20 points into a sprint. There are few very important points here though!
- Velocity and capacity are not the same – velocity looks at the past, capacity looks at the future; velocity describes what was done, capacity discusses what might be done (or attempted)
- Velocity should be an average – at least a three sprint rolling average, if not longer
- Velocity should be just ONE of the inputs into a discussion of capacity.
The final point is the most important so I will go further into it.
When a team in Scrum is choosing how much work to pull into a sprint, they should look at a number of different factors. Velocity is often one of those, and it might be a good one to start with – but don’t stop there! The team should adjust it based on other things that are planned to happen, or that might happen, during the sprint.
For example, if a team has a three or four sprint rolling average velocity of 20, then they might start with a capacity number of 20. That is, they start thinking about 20 story points worth of work to bring into the sprint.
However, they should then start modifying that number, based on:
- are there any public holidays coming up this sprint
- are there any people in the team taking annual leave this sprint
- are people in the team booked into training, conferences, etc. this sprint
- is there any work carried over from the last sprint this sprint that still needs to be completed
- are there any outstanding defects, bugs or production issues that the team will or might need to work on
- are there any outstanding technical debt or cleanup tasks that the team will or might need to work on
- will people in the team be called on to help others in the organisation this sprint, e.g. onboarding new members, running training sessions or creating documentation, helping out another team with a difficult piece of work, etc.
As you can see, there are many, many other factors that can go into determining the capacity of a team. And remember that unlike velocity (which is a historical metric), capacity is a forecast, an estimate. Nobody knows how much work the team will be able to complete until the sprint is over and the points are added up.
So don’t stress it too much! Remember that predictability is nice but value delivery is more important. If velocity and capacity discussions are taking up a lot of your team’s time and energy, just move on and get to work!
Conclusion
I hope you found this article helpful, and that you now understand the difference between velocity and capacity. Do you have any particular experiences or questions about this topic? Please let me know in the comments!
