Velocity is a popular tool that many Scrum teams use to size and forecast work. But so many organizations equate “velocity” to team “performance”, and that is not what it’s for.
First – what is velocity?
Velocity is a metric that measures the amount of work a team completes during a single Sprint. Here’s how. Scrum teams who are using velocity to plan their work will assign a point value to higher-ordered items in the Product Backlog. The point value assigned to each Product Backlog item takes into account effort, yes, but also complexity, risk, and uncertainty. For example, if the team simply doesn’t know how much work something might take, it could be assigned a higher point value based on this uncertainty.
During the Sprint, the Scrum team turns Product Backlog items into done product. At the end of the Sprint, the point values assigned to all of the Product Backlog items that are completed during the Sprint are added together, and this becomes the Scrum teams’ velocity for the Sprint. Velocity can be graphed over time to show how much work the Scrum team typically completes in a Sprint.
The Product Owner can use velocity information from previous Sprints to create a forecast of where the Scrum team might be one or more Sprints from now. Velocity can also be a helpful tool to aid the Scrum team, because during the Sprint Planning event, the Scrum team can consider how many points that they completed in previous sprints and use that information to determine how much work they should be able to complete in the upcoming Sprint.
Here’s the problem with velocity
While velocity can be a helpful tool for the Product Owner and the Scrum team, it is not intended to be a measure of success. Too many managers learn about velocity and try to use it as a measure of success for the Scrum team. Or worse, some leaders mistakenly use velocity as a way to compare the performance of two different Scrum teams to each other.
Below are 10 reasons why velocity should not be used as a measure of success or to measure the performance of Scrum teams against each other.
1. It’s an arbitrary number. Teams select their own point system and decide what points to use for different types of work. Because velocity is just a planning tool for the Scrum team, that’s fine. But if you try and compare the velocity of Team 1 with the velocity of Team 2, it’s meaningless. Even if they use the same point system, some teams may decide that a change to the layout of the product details page is a 3, and others may rate the same work as an 8. There isn’t a right or a wrong way to size work – it’s just that the team decides how to size work for them.
2. Inflation of Story Points: Even if two teams size work similarly, when you start comparing teams using velocity, you will eventually ruin velocity as a planning tool. Because teams get the idea that they are being judged by velocity, they will automatically start to inflate their points. This makes forecasting data meaningless.
3. Differences in Team Composition: Teams have different members with varying levels of experience, skills, and expertise. A team with senior developers may complete tasks faster than a team with junior developers, affecting their velocity.
4. Varying Complexity of Work: The complexity and nature of tasks differ across teams. One team might be working on more complex or innovative features while another is handling maintenance and minor updates, leading to differing velocities.
5. Different Definitions of Done: Teams may have different criteria for what constitutes a “done” task. One team might include thorough testing and documentation, while another may only consider coding completion, impacting their velocity.
6. Team Dynamics and Communication: The efficiency of team communication, collaboration, and overall dynamics can significantly influence productivity. Teams with better synergy and fewer conflicts will likely have a higher velocity.
7. Technical Debt and Legacy Code: Some teams might be dealing with more technical debt or legacy code, which can slow down their progress compared to teams working with newer, cleaner codebases.
8. Tooling and Development Environments: Differences in development environments, tools, and technologies used by teams can impact their efficiency and, consequently, their velocity. Better tools can streamline work and improve velocity.
9. External Dependencies and Interruptions: Teams might face different levels of interruptions or dependencies on external teams or systems, affecting their ability to maintain a consistent velocity.
10. Sprint Goals and Focus: Teams might have different sprint goals and focuses. One team might prioritize speed and quantity of work, while another might prioritize quality and thoroughness, leading to different velocities.
Conclusion
Rather than judging teams by their velocity, organizations should focus on measuring the value provided to customers. This can be achieved by evaluating customer outcomes, which directly reflect the effectiveness of the product or service in meeting customer needs. Key strategies include leveraging customer feedback and satisfaction metrics such as Net Promoter Scores (NPS) to understand customer sentiments and experiences. Additionally, tracking business outcomes like revenue growth, customer retention, and user engagement offers a clearer picture of the tangible impact of the teams’ work. Monitoring the real-world impact of delivered features through usage analytics and behavioral data can also reveal how well the solutions address customer problems and contribute to strategic objectives. By prioritizing these measures, organizations can ensure that their efforts are aligned with delivering meaningful value to customers, which is ultimately the core purpose of their business.
Rather than using velocity, Scrum teams should consider using flow metrics to plan their work. To learn more about using flow metrics as well as other techniques such as limiting work in progress to plan work, signup for Rebel Scrum’s Professional Scrum with Kanban course.