If you have already been in the Agile world for some time, you have probably heard of capacity and velocity – even though you may never have used these concepts or fully understood them. If that is the case, do not worry. The first time I heard these terms, they did not make much sense to me either.
Both are performance and productivity indicators, with names that sound more sophisticated than they really should. Although they are often treated as similar, capacity and velocity are not the same thing. On the contrary: they are completely different metrics that, when used together, help to have a clearer view of the team’s current situation and the relationship between workforce and sprint size.
What is capacity?
Capacity represents how much work a team can support in a period (usually a sprint). Normally expressed in hours, but it can easily be converted into days or weeks. In short, it is the team’s effective availability.
How to calculate?
Capacity = sprint length × working hours per day × number of people
Example:
A team of 5 people, each working 6 hours per day, in a sprint of 15 working days:
Capacity = 15 × 6h × 5 = 450 hours
In other words, capacity is nothing more than the total number of hours available for the sprint.
What is velocity?
Velocity shows how much, on average, a team can deliver per sprint, usually measured in story points.
Example: consider the last 5 sprints of a team:
- Sprint 1 = 30 points
- Sprint 2 = 40 points
- Sprint 3 = 30 points
- Sprint 4 = 32 points
- Sprint 5 = 29 points
The average will be:
Velocity = (30 + 40 + 30 + 32 + 29) ÷ 5 = 32.2 points per sprint
In other words:
- Capacity is a theoretical number (available hours / available workforce).
- Velocity is an empirical number (what the team with that capacity actually delivers).
How do capacity and velocity complement each other?
Think of capacity as the “available workforce” in hours. This number alone does not tell how many stories will be delivered.
Velocity, on the other hand, shows how much the team actually delivers on average per sprint. In theory, if capacity increases (more people or more hours), velocity also tends to grow. But this relationship is not always linear: team experience, story complexity, and team synergy also matter.
How do I know how many cards to put in the sprint considering the current capacity?
This is the question that almost every PO or SM has already asked themselves. But there is no exact formula like X hours = Y cards, because the size of the stories varies a lot. What you can do is:
- If the team estimates in hours: add up the hours of the cards until you fill the calculated capacity.
- If the team estimates in story points: use the average velocity as a reference, not the capacity in hours.
I know you may still be confused, but below I’ll give you a tip about when capacity can be extremely useful.
The trick 🐱
The real value lies in knowing when to use capacity, velocity, or both together.
- If the team’s total capacity is 450h, but the average velocity is 32 points, planning should be done around 32 points – not 450h.
- If the total capacity is 450h, but a developer will be on vacation, you will have fewer available hours. This affects capacity and, consequently, should lead to a lower velocity forecast for the next sprint.
- If you are forming a new team, you can calculate capacity and think of an approximate number of points to assign to the team, considering its capacity. Of course, this is just an approximation, but our job is also to try to predict things, make mistakes, and correct quickly.
In summary: capacity measures availability, velocity measures delivery. One helps to understand the potential, the other to measure reality. And together, they give much more clarity for sprint planning.