Velocity - A tool to measure Agile team delivery rate
What is Velocity? Velocity is an extremely simple yet effective method to accurately measure the pace at which the Development Team consistently delivers work. Velocity represents the average amount of Product Backlog that is transformed into a product increment within a Sprint, and it is tracked and utilized by the Development Team. To calculate a team’s velocity, we simply sum up the estimates of the features, user stories, requirements, or backlog items that have been fully completed during an iteration (Sprint).
In the article about Story Point, we mentioned Velocity as the total number of story points completed in each Sprint. Velocity is considered a historical performance metric used by Agile teams to understand their capacity based on past performance. So, what exactly is velocity, how is it used, and how does it support Scrum teams? Let’s explore these aspects in detail in the following article.
1. What is the definition of Velocity in Agile?
Velocity is an extremely simple yet effective method to accurately measure the pace at which the Development Team consistently delivers work. Velocity represents the average amount of Product Backlog that is transformed into a product increment within a Sprint, and it is tracked and utilized by the Development Team. To calculate a team’s velocity, we simply sum up the estimates of the features, user stories, requirements, or backlog items that have been fully completed during an iteration (Sprint).
Understanding Velocity in Agile
In other words, velocity can also be defined as "a metric that represents a team's work capacity per iteration." It helps measure the amount of work a Scrum Team can handle in future iterations (sprints), based on the amount of work they have completed in previous ones. This enables the team to track and communicate their actual output, forecast what they will likely be able to deliver in upcoming sprints, and forecast when a project (or release) could potentially be completed.
2. The relationship between Velocity and Story Points in Scrum
Story points are used to estimate the size and complexity of the work required to implement a specific user story. The total number of story points completed in each Sprint is tracked as the project's velocity. This forms the basis for understanding a team's delivery capacity over time. So, what is the relationship between velocity and story points?
Teams often use “velocity” as a productivity metric to communicate the exact pace of the Scrum team to users or customers.
If the team’s estimation of story points is maintained throughout the project, it makes sense to use the story point to represent “velocity”.
When consistency is maintained not only within a single team but also across multiple teams - and even at an organization-wide level - velocity can serve not only as a measure of productivity but also as a benchmark for comparing the performance of different teams.
If the value of the story point is stable, then it can be used as a reference for the release planning, enabling the team to assess realistic delivery timelines and future progress.
3. How to accurately estimate Velocity
In Scrum, velocity helps us understand how long it will take for a team to complete the Product Backlog. However, it usually takes several Sprints for the team to figure out a more stable velocity. To estimate velocity more accurately, teams can leverage their historical performance data. This provides a more reliable forecast of the number of story points a team can complete in a Sprint. For forecasting purposes, it is recommended to use the average velocity from the last three or four Sprints.
For example, let’s assume a new Scrum team planned to complete 39 story points in their first Sprint, but they were only able to finish 38 story points. In this case, the velocity would be 38, as illustrated in the figure below:
How to accurately estimate Velocity
Generally, velocity tends to fluctuate the most during the first few iterations and then gradually stabilizes. This happens because the team needs time to get used to working together, become familiar with project tools, and interact comfortably with project stakeholders. As the product grows, there will be more activities related to maintenance, refactoring, and potentially supporting earlier product releases if they have already been deployed. Overall, as the project complexity increases over time, velocity tends to stabilize accordingly.
4. Average Velocity based on past Sprint records
If a task or user story is only partially completed, it should not be counted toward the team’s velocity. Only user stories that are marked as “Done” are included, even if there is only a small amount of work left to finish.
Based on a single initial Sprint, velocity is not yet a reliable metric for making accurate forecasts. However, it helps the team understand how much work they can realistically commit to in a Sprint, as well as track their progress within that Sprint.
Now, let’s say the team continues development through Sprint 4. Their story points completed were 38 in the first Sprint, 29 in the second, 38 in the third, and 39 in the fourth. Thus, the estimated average velocity after 4 Sprints is 36, as shown in the figure below:
5. Velocity indicates how many Story Points your team can complete in a Sprint
At the end of each Sprint, we can count the total number of story points that have been completed and approved by the Product Owner. Many teams visualize their velocity per Sprint using bar charts, allowing them to see how they have performed over multiple Sprints. Since each team may use a different story point estimation scale, velocity cannot be used to compare different teams with one another.
- Sprint velocity
The following bar chart shows the total number of story points completed across four Sprints. If the team uses the same estimation scale for each Sprint, they can leverage this data to compare the amount of work completed from one Sprint to the next. To create this chart, the team simply sums up the number of story points in the “Done” column on the task board at the end of each Sprint (we will explore Task Boards in more detail in future articles).
- Sprint Velocity with committed points
The chart below shows the total number of story points the team initially committed to in each Sprint (shown in gray) versus the number of story points they actually completed (shown in black). To create this chart, the team adds up all the story points in the Sprint Backlog after Sprint Planning and marks that as the committed value. At the end of the Sprint, they calculate the actual velocity by summing up all story points in the "Done" column of the task board.
Based on the velocity from previous Sprints, the team can achieve the following objectives:
- Track the amount of effort the team reported as completed in each Sprint.
- Estimate how much effort the team can handle to work through the backlog in future Sprints, assuming the team composition and Sprint duration remain unchanged.
6. Conclusion
The purpose of tracking velocity is to improve a team's ability to consistently and reliably estimate the amount of work they can complete. We hope this article has helped clarify what velocity is, how it can be effectively used, and how it contributes to achieving optimal team performance toward shared goals.
Knowledge compiled by Trainer Nguyễn Hải Hà (PMP®, PMI-ACP®, PMI-ATP Instructor, PSM II)
References: PMI-ACP Exam Prep by Mike Griffiths, Head First Agile, Visual-paradigm
See more
Story Map - A key planning tool in Agile projects
Tracking Agile Project Progress with Burn-down and Burn-up Charts