In the Scrum framework, velocity is an important indicator of how much work a Scrum team can handle in a sprint. It measures the average amount of work a team can take in a single sprint, so many Scrum teams use it for forecasting work. However, some organizations link velocity with team performance or success, which is totally wrong.
The purpose of the velocity metric is not to measure success. To better understand this concept, this guide will clarify the role of the velocity metric and justify why it is not meant to measure performance or success. So, let's get started!
Velocity is a Scrum metric that reflects the amount of work a team can handle in a single sprint. Mostly, teams present velocity in story points, which is a unit of measure to size backlog items or user stories in terms of their risk, complexity, or uncertainty.
The velocity is calculated at the end of the sprint by summing points of all the completed user stories. For example, consider that a team is working on creating the login page of an app. So, the story points based on the complexity of backlog items can be as follows:
Once the team has completed all the above backlog items (or user stores), the team velocity for this sprint is 34 points. The team can now use this velocity to forecast work for future sprints.
After completing a few sprints, the team will be able to better guess its average velocity and plan how much work they can complete on average per sprint.
By now, we have learned that velocity is a metric that helps the team to better forecast the work and ensure that they only pick the work they can complete within a sprint.
The basics of velocity are itself self-evident; it is meant for forecasting or predicting work, not to measure team performance or success. However, let's understand it better by listing some of the valid reasons to justify why organizations should not use velocity as a measure of performance/success:
Velocity is a number based on story points, and every team defines a story point system of their own. There isn't a standard formula to define story points for user stories. So, you may see a team with a velocity of 13 points while another team with a velocity of 34 points. In such cases, how can we say that the first team's performance is poorer than the second team's if their point system is different?
Even if teams use the same point system, they may still assign different story points for the same user story. For example, team A is more experienced in creating login pages, so it assigns 3 points for integrating Google Sign-in. However, team B is new to creating login pages and assigns 8 points for integrating Google Sign-in. Therefore, it does not make sense to consider velocity to measure team performance or success.
As evident in the first point, team composition also influences velocity. A team with experienced developers can complete user stories at a much faster pace, so they may assign lower story points to even complex user stories.
In contrast, a junior developers team needs more time with user stories and can assign higher points for complex user stories. So, if the velocity of a senior developer team is 15 while that of a junior developer team is 20, can you say that junior developers are better at performance? This point again validates that velocity is ineffective in measuring performance or success.
Not all teams work on tasks with the same complexity level. Some handle innovative features that require more brainstorming and bugs. In contrast, others handle minor updates or fixes. So, they will have different velocities, which cannot define their performance or success.
Different teams have different sets of technologies, tools, and development environments. These differences impact their efficiency. For example, a team using the latest AI-integrated development tools can progress faster. So, its velocity may have lower points than the team currently using traditional development tools.
Technical debt refers to rework the team has to undertake in the future due to taking shortcuts or choosing easier solutions in the present. This happens when a team opts for a quick, less optimal solution that saves time and effort in the short term but requires more work to fix or improve later.
Teams often involve more technical debt. Due to that, their performance will be low compared to teams working on fresh items. So, velocity cannot define the efficiency of their performance or indicate which team is more successful.
The Definition of Done (DoD) is not the same for all teams. Some teams consider a backlog item done once it is thoroughly tested and documented, while others consider it done once they have completed the coding part. So, varying DoD also means varying velocity.
Different teams can have different levels of external interruptions or dependencies. It can be related to systems, other teams, or stakeholders. These influence their performance and velocity. So, if an organization values velocity as a measure of success, these teams will be considered less successful compared to teams with fewer interruptions or dependencies. This is incorrect because it does not reflect the actual effort of the teams.
Not all teams have the same sprint goals. Some teams are more focused on quality and details, while others are more focused on quantity and speed. So, varying sprint goals mean varying velocities, which means varying performances.
Team productivity is linked to its different dynamics, such as communication practices, collaboration environment, and other factors. A team that is more collaborative and involves fewer conflicts can be more productive and have better velocity.
Similarly, team size can also influence velocity. A large team can have a higher velocity due to more hands on deck, but it faces more conflicting situations. In contrast, a smaller, well-coordinated team may have a lower velocity but can operate more smoothly.
In an organization where teams are evaluated based on velocity, it can impact the integrity of velocity as a planning tool. The teams will inflate their velocities with story points just to make them look like they have higher velocity. Doing so will make velocity an ineffective tool to forecast work and become a competition metric.
From the above decision, we can clearly conclude that velocity is not meant to measure the performance of success. Instead, organizations should use other ways to achieve this. They should evaluate the effectiveness of the deliverables in meeting the customer expectations. For that, they can ask customer feedback to understand their satisfaction.
In addition, organizations can evaluate revenue growth, user engagement, and customer retention as measures of success. In short, there are plenty of ways and metrics to measure the success of Scrum-based projects. Therefore, the wrap-up is to leave velocity as a metric for forecasting work and focus on other effective metrics to measure project success.
Read more: How to Improve the Team Velocity in Scrum?
