Connected to the principle of iterative development, velocity in Agile is used to measure how much work can be completed in each iteration. It is widely used as a calibration tool to help development teams create accurate and efficient timelines.
Lean and Agile Metrics: Oh, my!
Learn how you can manage WIP limits, size features, view velocity, burndown and so much more with the Planview Agile Program Management solution.
Voir le webinaire • Métriques Lean et AgileGestion de programmes Agile : connecter et visualiser toutes les activités
Découvrez les défis auxquels sont confrontées les organisations en cours de transformation et comment les logiciels Kanban d'entreprise peuvent vous aider à assurer efficacement la gestion de programme Agile.
Consulter l'e-book • La gestion de programmes Agile
Velocity in Agile is not meant to be used as a goal or benchmark to strive for because it is measured relatively depending on what makes the most sense for the team measuring it. While maintaining consistency is ideal, Agile velocity is meant to be used mainly as a planning tool.
How is Velocity in Agile Measured?
Velocity in Agile is a simple calculation measuring units of work completed in a given timeframe. Units of work can be measured in several ways, including engineer hours, user stories, or story points.
The same applies to timeframe; it’s typically measured in iterations, sprints, or weeks. However, you decide to measure velocity should be how you continue to measure it going forward.
For example, to track Agile velocity, most Scrum teams measure the number of user points in a given sprint. Once this is measured based on a few sprints, the team can then predict how many user points they should plan to complete per sprint. This ultimately reveals how many sprints it will take to complete a project, and helps the team to measure efficiency along the way.
How Does Agile Velocity Help Measure Efficiency?
The raw numbers of Agile velocity will not reveal much; it is the trends that will help you measure and improve efficiency. A misconception about velocity in Agile is that it should be used as an efficiency goal, which is not the intended use case.
Here is a common mistake that gets made because of this misconception: When a team sees velocity numbers decreasing, they ask “how can we get the number back up to where it was?” This runs the risk of pressuring developers to cut corners in order to achieve a particular velocity goal.
Instead, when your Agile velocity numbers are trending down, it should signal you to dig deeper into possible inefficiencies that may be causing the downward trend. If you are confident that there aren’t any, then you may want to plan for a lower velocity number going forward. This would yield a more accurate budget and timeline.
Likewise, an increase in Agile velocity numbers should be looked into as well. It could be a sign that the team is moving too fast and quality has declined.
If that’s not the case, and you find you can accomplish higher velocity numbers than planned for – without risking quality – you can shave a few iterations off of the overall timeline.
The best way to use velocity in Agile is to keep it simple and let it guide you to uncover inefficiencies in your process.
There is no ideal velocity number; an upward trend is not necessarily a good thing and a downward trend is not always negative. But both will signal you to dig deeper into areas of the development process that can help you achieve efficiency while maintaining technical quality.
