HomeBlogVelocity is a...
July 12, 2024
6 min read

Velocity is a Forecasting Tool, Not a Success Metric in Scrum

Velocity is a Scrum metric that helps teams forecast the work for upcoming sprints. It is not meant to measure team performance or success. Keep reading to learn why velocity is not a success metric in Scrum.
Anton Versal
Anton Versal
Let's look into the velocity and not confuse it with the success

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!

What is Velocity? A Quick Overview

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:

  1. Design the login page UI: 5 points
  2. Implement the login form with email and password fields: 3 points
  3. Integrate social login options (Google, Facebook): 13 points
  4. Create "Forgot Password" functionality: 5 points
  5. Add error handling and feedback messages: 3 points
  6. Ensure mobile responsiveness and cross-browser compatibility: 5 points

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.

Why Velocity is Not an Indicator of Success?

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:

1. Velocity is a Random Number

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.

2. Varying Team Composition

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.

3. Varying Work Complexity

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.

4. Workspace Environment

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.

5. Technical Debt

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.

6. Varying Definition of Done

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.

7. External Interruptions or Dependencies

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.

8. Varying Sprint Goals

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.

9. Varying Team Dynamics

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.

10. Story Points Inflation

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.

Wrapping Up – Measure Project Success Through Other Ways

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?

Read more

July 4, 20247 min read

How to Improve the Team Velocity in Scrum?

Team velocity in Scrum reflects the team's productivity and proficiency. Having a balanced team velocity leads to many benefits. So, stick with this guide to learn the best tips to improve the team velocity in Scrum.Team velocity or Sprint velocity is an important metric in Scrum. It helps to track the efficiency and productivity of a Scrum team. Furthermore, it gives stakeholders a general idea of the team's capabilities and what to expect from them Sprint by Sprint. Ideally, a Scrum team should have a…
August 25, 20237 min read

How to Measure Success in Scrum Agile Methodology

Since Scrum is a unique approach to project management, measuring success in Scrum is also more complex. So, keep reading this guide to learn how to measure success in Scrum Agile methodology using six key metrics.Organizations from various industries are embracing agile methodologies, like Scrum, to modernize operations, enhance productivity, drive innovation, and deliver value to customers faster. With the structured, incremental approach to project management, Scrum is helping hundreds of thousands of…
April 1, 20225 min read

Why Does Planning Poker Use Story Points Instead of Time Values?

Oftentimes, people get confused between story points and time values when estimating with Planning Poker. Well, we’re here to clear up the confusion.Without a doubt, estimation is a difficult undertaking. It is one of the most challenging — if not the most difficult — facets of the job for software developers. It must consider various elements to assist product owners in making decisions that influence the entire team and the company. Product…