by Jason Gardner (ed.)
Stop Abusing Velocity as a Comparison Metric in Scrum
The Scrum framework promises teams greater velocity and efficiency when approaching complex projects. However, without careful consideration for the key nuances within the methodology, organizations can quickly start to lose track of their bottom line objectives. Velocity should not be thought of as a “catch-all” measure, but rather as one way that teams can evaluate how productive they are – especially compared to previous iterations and forecasts. In this blog post, we’ll explore why velocity isn’t an ideal metric for comparing similar projects across different teams – and discuss strategies you can implement so that you have a more holistic view into your team’s progress towards success.
Introducing Velocity as a Comparable Metric in Scrum
As Scrum continues to gain popularity as a project management approach, there has been a need to find an effective metric to measure team productivity and efficiency. Enter velocity – a measure of how much work a Scrum team completed in a single sprint. This metric has gained traction in recent years as it provides a clear understanding of how much a team is delivering at a given time. The beauty of velocity is its ability to facilitate comparisons across sprints from the same team. This metric allows for a standard and consistent way of measuring productivity and progress, making it a valuable tool for any Scrum team.
The Pros of Using Velocity as a Metric in Scrum
Velocity, as a metric in Scrum, has multiple benefits that can enhance a team’s productivity and efficiency. One of the most significant advantages is its ability to help teams measure their level of progress over time. By tracking their velocity, teams can gain insights into how much work they can accomplish in a given sprint. This helps them set realistic goals and better plan for the future.
The Cons of Relying on Velocity as a Measurement Tool
In our fast-paced world, time is of the essence. Businesses strive to produce products and services efficiently, and in doing so, velocity has become a popular measurement tool. However, relying solely on velocity to gauge productivity can be risky. Focusing solely on speed can lead to low-quality products or services. It can also foster a cut-throat work culture that puts employees under immense pressure to perform quickly rather than well. As such, while velocity can be a useful tool in improving productivity, it is important that businesses also consider the quality of the product and morale of their employees. It should never be seen as a standalone metric but rather used in conjunction with other measurements for a well-rounded picture.
It’s also important to not use velocity to compare different teams. Velocity is based on a calibration that is specific to each team. So, if one team has a velocity of 20 and another has a velocity of 40, it doesn’t mean that one team is doing better or worse than the other. Trying to force a comparison will lead to each team modifying their scale. Velocity should be used for forecasting and evaluating experiments, not as a comparison tool.
Velocity is also not a measure of value, only of how much was accomplished. Don’t fall victim to thinking that delivering more always means better results. What we’re really after is customer value – and wouldn’t it be better if we could deliver that with less effort, not more?
Tips for using velocity correctly within the Scrum Methodology
So how do you use velocity responsibly? One option is to analyze velocity trends without relying solely on velocity numbers. Especially if communicating with those outside of the team who don’t understand that velocity is calibrated to the team, it can be helpful to show them the graph of the velocity trend, but without the numbers.
Also, teams should use velocity to not overcommit in the sprint. Too often teams will have an idea how to improve, and commit to more before they have validated the change. They are, in essence, banking on a benefit that they haven’t seen yet. It’s better to implement the change first, measure the outcome, and then commit based on the new demonstrated velocity.
Another approach is to forecast with a date range instead of a single date. The further out a forecast goes, the higher the likelihood of variance. You can use your highest velocity and lowest velocity to help determine that range.
For example, take a team that has been asked to forecast when they will be able to accomplish a major milestone, which has been estimated at 200 story points. They’re average velocity is 40 story points. Their highest demonstrated velocity is 50, and their lowest is 30. The absolute soonest this team could deliver that milestone would be 200/50, or 4 sprints (2 months). But that would require everything going right every sprint. The expected delivery would be about 200/40, or 5 sprints (2.5 months). If everything were to go horribly every sprint, we would deliver in 200/30, or 7 sprints (3.5 months). So, this team would have about a 5% chance of being able to deliver in 2 months, 80% chance of being able to deliver in 2.5 months, and a 95% chance of being able to deliver in 3.5 months. Giving this range helps communicate the uncertainty inherent in forecasting the future but is also based on actual demonstrated delivery. It also tends to be accurate enough for stakeholders to make meaningful decisions.
Another important technique is to remeasure velocity when team composition changes. Adding or removing people from the team (even if one person is removed and another added in their place) will change the velocity of the team. It’s important to measure the new velocity of the team and update any forecasts using the new velocity.
Conclusion
As we’ve seen throughout this post, velocity is an incredibly useful metric when it comes to analyzing delivery in a Scrum setting. However, it can’t be the only gauge used to accurately measure success for a Scrum team. Understanding common pitfalls and making sure to use velocity wisely can help teams draw more structured conclusions. To become versed in Velocity-focused metrics and improve your ability to strategize and evaluate in a Scrum environment without always resorting to familiar calculations, take a Platinum Edge CSM or CSPO class. Being well-versed in those skills will serve you well as you plan out your approach to project management within the boundaries of the Scrum methodology.
