The following article is part of the self-preparation for the modern BVOP® Scrum Master Certification program.
Velocity is a fundamental concept in Agile development that refers to the amount of work a team can complete within a given sprint. Calculating velocity accurately is essential to predict project completion and ensure successful delivery. In this article, we will explore what velocity is, how to calculate it, and why it matters. We will provide step-by-step guidance on how to determine team velocity and share tips on improving it. Understanding velocity calculation is crucial for Agile teams to manage projects effectively, stay on track, and deliver high-quality products. So, let's dive in and discover what velocity is, how to calculate it, and why it's so important in Agile development.
- What is the velocity of Agile and Scrum teams?
- Velocity is a term in Agile product development
- What can we use Velocity for?
- Relativity and Velocity
This chapter explains the specific concept of Team Velocity, which is typical of Scrum and Agile-oriented teams.
What is the velocity of Agile and Scrum teams?
Velocity is a measure of work the Team performs during a single Sprint and is measured at the end of the sprints by calculating the Points of completed User Stories. Knowing velocity, the team can estimate how long the project will take to complete.
Velocity is a term in Agile product development
Velocity is a term in Agile product development disciplines and is increasingly used today not only by Scrum teams but also by Project Management and Product Management roles.
Velocity is the "speed" at which teams complete planned tasks. It's easy to understand the concept, and at the same time, it's а simple idea.
Velocity needs a fixed period
To be able to measure the "velocity" of a team, some agreed-upon period should be set for active work. This period could be your Sprint.
Calculating Team Velocity
During a Sprint, the entire team completes tasks or User Stories. At the end of the Sprint (a week or two weeks, or any other period), the team completed, for example, 10 User Stories (Product Backlog Items).
Each of these 10 tasks, User Stories or Product Backlog items, had specific Story Points. A Product Backlog item was rated 3 Story Points. Another was rated 8. Some could be 1 or 21.
If we add up the total of these completed 10 items during the Sprint, we get a number. For example, 133.
133 is the Velocity value of the team.
What can we use Velocity for?
Planning Sprint work
After we have calculated the Velocity of the team, it can be easier to predict how many tasks or Product Backlog items can be completed by the Development team in the next period (Sprint).
If 133 was the Team Velocity of the past Sprint, the new planned Product Backlog Items with their Story Points need to have a total sum of about 133.
When that sum reaches a total Story points of about 133, you can count on the fact that those planned Product Backlog Items will be successfully developed by the team during the next Sprint.
Suppose the Development team consists of 5 participants. They all completed 133 points of work.
If you divide 133 work points amongst 5 participants, you will receive 26.6. Let's round this number to 27. So we can roughly say that one member of the Development team completes 27 points in one Sprint.
Business stakeholder and Team Velocity
If a director or business stakeholder asks you to accelerate project work by increasing the size of the team, you may assume the following:
If you add another specialist to the team, the points for the next Sprint, instead of 133, will already be 133 + 27 = 160. Ideally, this means that for one Sprint, the team will complete 160 points of work. Thus, instead of a total of 10 items, these 160 points may include, for example, 15 items. Your business stakeholders will be satisfied with faster development.
If one participant leaves the team, you simply subtract 27 from 133 to get 106. The team can produce such work points during the next period (Sprint) if you are left without one participant.
Once you have the team velocity measured in points, you can theoretically calculate an unlimited number of Product Backlog Items in the future and determine how many Sprints (periods, weeks, months, etc.) will be required to complete all items.
Relativity and Velocity
Some important topics to keep in mind about the Velocity:
The further in time you plan, the more inaccurate your estimates will be.
The longer the team works together, the more work (Story) points they can develop over a period.
If you add a new member to the team, keep in mind that the team needs to unite again before you can predict with greater accuracy the Velocity of your team.
If one participant leaves the team, this does not mean that a certain number of points must be subtracted from the total Velocity. This participant may have worked with different capacities.
Everything is relative.
If you change your technology and tools, Velocity will temporarily decline as teams gain substantial experience with new resources and speed up again.
Various factors in a project or organization can affect Velocity's value.
The following issues related to chapter "Team Velocity" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of September 7, 2024, 2:46 pm
| ID | Issue | Time | Category |
|---|---|---|---|
| 0 | What can we use Velocity for? | 60 sec | SM, PO |
| 1 | Business stakeholder and Team Velocity | 60 sec | SM, PO |
| 2 | Velocity is a term in Agile product development | 60 sec | SM, PO |
| 3 | What is the velocity of Agile and Scrum teams? | 60 sec | SM, PO |
| 4 | Planning Sprint work | 60 sec | SM, PO |
| 5 | Relativity and Velocity | 60 sec | SM, PO |
| 6 | Calculating Team Velocity | 60 sec | SM, PO |
| 7 | Everything is relative. | 60 sec | SM, PO |
| 8 | Velocity needs a fixed period | 60 sec | SM, PO |
- Previous article Relative Estimation
In this case, I would recommend tracking the team's velocity for the new one-month sprint separately from the previous one-week sprint. This will allow you to better gauge the team's productivity during the new sprint length and make more accurate predictions for future sprints. Additionally, you may want to consider averaging the velocity of the new one-month sprints separately from the previous one-week sprints to avoid skewing the overall average.
It's also worth noting that velocity is not the only metric you should be tracking to ensure successful project delivery. Consider using other metrics like burndown charts, cumulative flow diagrams, or lead time to gain a more comprehensive understanding of your team's performance. Good luck!