What is Velocity? Should we use it as a metric?
Photo by Lee Aik Soon on Unsplash
Velocity is the amount of work completed by the development team within each sprint, typically between two and four weeks. Velocity is measured in either story points or a numeric value, for example, the hours needed to complete a user story. The finished work is the summation of these assigned points for user stories that have been fully developed and tested.
If you are not familiar with Story Points, this article can be helpful:
What are Story Points? How to use them?
Velocity can be used to approximately know how long is going to take to complete a set of user stories. Let’s say the Product Owner wants to complete a certain number of user stories and the amount of work identified by the development team is 500 story points. We know that the development team generally completes 50 story points per iteration. The Product Owner can reasonably assume, that the team will need 10 iterations (give or take) to complete the required work.
From the above example, you can think that we measure speed, but that is wrong, velocity is a measure of capacity. When teams calculate velocity they measure the sum total of what they do for a given iteration. That total is a rough approximation of capacity. If your stories are small, the variation doesn’t matter so much. But when the variation is large, teams encounter problems.
It is important to monitor how velocity evolves over time. New teams can expect to see an increase in velocity as the team optimizes relationships and the work process. Existing teams can track their velocity to ensure consistent performance over time and can confirm whether a particular process change made improvements or not. If a decrease in average velocity is detected, it should be brought up at the next retrospective, make an analysis and act accordingly. Keep in mind that can be many reasons behind a fluctuating velocity sprint to sprint that have nothing to do with Development Team performance or Agile maturity: sprint backlog item synergy, dependencies, item complexity or difficulty, context switching, production support, the list goes on…
Each team’s velocity is unique. If team A has a velocity of 50 and team B has a velocity of 75, it doesn’t mean that team B has higher throughput. Since each team’s estimation culture is unique, their velocity will be as well. Resist the temptation to compare velocity across teams. Measure the level of effort and output of work based on each team’s unique interpretation of story points.
It is incorrect to see Velocity as a performance metric. Velocity is more like a planning metric to help both the Development Team and the Product Owner to plan future sprints.
Velocity is an output-based metric, which tells us nothing about the value being delivered. It is just a number telling us how much “stuff” a Development Team typically cranks out in a sprint. While it may be a guide to how productive a team is, there can easily be situations where a small number of story points deliver much more value than a large amount.