Difference Between Velocity & Capacity: A Product Manager’s Perspective

March 25, 2020
|In Product
|By Left

Velocity

The number of story points delivered in a sprint is called Velocity.

For example, if a development team planned a sprint, and points from all of the stories was 30, but at the end of the sprint, the team delivered 27 points. The team’s velocity would be 27.

From a product manager or product owner’s perspective, this metric can we a useful tool to plan future work. From a development team’s perspective, it can be used as a KPI to monitor the health development teams.

Velocity For Future Projects

Velocity can be a helpful KPI to plan/forecast either future projects. It can also help give insight into when current projects may be completed.

If you want to do this, track the average velocity over the last 4 sprints. Using individual sprint velocity won’t work as well since single sprint velocity varies from sprint to sprint due to vacation/leave, sick days, etc. By using that past 4 sprints, it provides a better gauge of the velocity for future sprints.

For example, if the velocity for the last 4 sprints were 23, 29, 35, 24, the prediction for future sprint velocity would be 27.75 (sum((23,29,35,24)/4).

In order for this to be a meaningful tool to help your team plan future work, it’s also important that the development team can estimate both user stories and project work relatively accurately.

Remember, when using a team’s velocity to plan future work, the number should be used as a guide but should not be used as a contract.

Velocity For Development Team’s ‘Health’

A ‘healthy’ development team will typically have consistent velocity sprint over sprint. This is achieved because of the team’s ability to estimate (point) work and plan sprints well (know what is realistic to complete in the sprint timeframe). Teams usually get better the longer they work together and the more consistent the type of work is.

Does having a high velocity mean the team is a good one?

I’ve been asked this a few times before, and the answer is no. Having a high velocity every sprint, or even a low velocity every sprint, doesn’t mean the team is a good or bad one.

I’d even argue that the actual number doesn’t matter. Every development team points stories differently. A 3-point user story for one team might be a 5-point user story for another. It’s more important that development teams point and complete stories consistently every sprint.

There are circumstances where consistently is really hard but we’ll get into that a bit later.

As a product manager, if you’re finding that a team’s velocity is inconsistent, it’s a good idea to diving deeper with the team and understand more information behind the numbers. Jump into the conversation with a collaborative mindset to discover more. Treat it like a user interview.

The better the development team and you get at this process of measuring output, the easier it is to collaboratively build a roadmap.

Things to understand about using velocity to track development team’s health:

  • Too much focus is bad: While consistency is a sign of a “healthy/mature” development team, focusing on it isn’t always the right thing. Too much focus on consistency velocity may hinder the developer’s ability for creative problem-solving. For example, if a better idea appears mid-sprint, which is out of scope from the existing idea, you want to encourage having conversations about this. If developers feel too tied to velocity tracking, they could choose to just do the existing story because that’s what is being measured.
  • Non-pointed work: In my experience, research and development (R&D, Spikes, etc.) aren’t pointed on purpose. I’ve also worked in environments where some companies pointed bugs and others didn’t. Non-pointed will lower velocity, and that’s ok. By knowing this, you’ll be able to understand that there’ll be a drop in velocity if projects need a lot of R&D. This is common in new technology projects.
  • Team changes: As development teams change, this will affect velocity. Adding new team members likely won’t increase the velocity at first, it can even decrease it while the team adjusts. After new team members get up to speed, the velocity should be higher than before the addition. If it doesn’t increase, it’s a good time to dive and in and do some discovery.
  • Unstable sprints: I define ‘unstable’ sprints as ones where stories are being added or removed mid-sprint. When this happens, velocity will be inconsistent.

Capacity

The total number of available hours for a sprint is called the development team’s Capacity. Available hours are calculated based on the number of available resources minus things like planned vacation/leave, company events, country holidays, etc.

Capacity is used to plan the sprint. The team commits to completing a set number of user stories/tickets within the sprint time frame. Points are used in the process to help gauge the difficulty of the story and to help gauge the feasibility of completing the sprint compared to past sprints.

For example, let’s say the team commits to 23 stories in a sprint and the point total for that sprint is 39; however in past sprints, the team’s average velocity (over the last 4 sprints) has been 27 points, the team should have a conversation why they’ve committed to more points.

If this happens, here are some things to ask/think about:

  • Is our available capacity higher in this sprint? (Fewer developers on vacation, no holidays in this sprint, etc.)
  • Can we outperform our average velocity? (New hires are contributing more, limited/no R&D in this sprint, last sprints had a lot of R&D, etc.)
  • Are there stories that have high points which may be a risk of not completing? Can we break those down into smaller stories to reduce the risk of rollover?
Latest posts by Left (see all)