What is Agile Velocity?
“Agile Velocity” is the amount of work a team can deliver in a set period of time (sprint).
Agile velocity is used to measure the rate at which an Agile development team delivers value to a business. For example, Scrum velocity will help you determine how quickly a Scrum team can complete the work assigned to them.
Uses of Agile Velocity?
To Estimate development time – Sprint velocity can be used to predict when the Agile team will be able to ship out the final product. For example, if you know how much work a team can finish during each sprint, you’ll know how many sprints the entire project will take.
To Identify team potential – A product owner and manager can use Agile velocity to determine if their Agile team became more efficient over the development cycle. If the team velocity consistently increases after every sprint, it shows that they are learning quickly. Increasing velocity also indicates that they are ready to handle more complex tasks.
Additionally, a project manager or Scrum master can use sprint velocity as one of the key Agile metrics to determine the team’s agility during their release planning meetings.
What is Velocity Chart?
A velocity chart is a visual representation of your project’s progress. It shows the amount of value delivered in each sprint, enabling you to predict the amount of work the team can get done in future sprints.
It helps project managers gauge their team performance easily. You can also highlight your team’s agility during sprint planning, sprint review, or sprint retrospective sessions, using a velocity chart. It helps you in making a decision on how much work you can feasibly commit to.
Velocity Chart Example
1. Sprints (X-axis)
X-axis displays the sprints completed by the team. ‘Sprint’ a measure of the development cycle time taken to complete a section of the project. A sprint length can be anywhere between 1-4 weeks.
2. Story points (Y-axis)
In the Agile velocity graph, the Y-axis can be used to measure the number of total story points that can be completed in one sprint by a team.
‘Story point’ is a measure of the effort you’ll need to complete your project tasks (each user story).
How do you calculate a story point?
The time taken to complete the simplest user story is taken as the baseline and is assigned 1 point. Similarly, the other user stories are assigned story points proportional to the baseline.
3. Estimation (Blue Bar)
The blue bar is the total story points the team is expected to complete in one sprint. After the sprint has started, any new user stories or changes are not included in this total.
4. Completed (Green Bar)
The green bar is the total story points the team has actually completed in one sprint. Any scope additions after the sprint has started are not included in this total
How to calculate Sprint Velocity?
Agile velocity can help team leaders estimate the number of user stories the team can handle in future sprints.
Project velocity is calculated by taking the average of the total completed story points (green bars) over the last five sprints.
Let’s calculate the team’s velocity in the above chart:
The team’s velocity is: (30 + 40 + 35+ 45) / 4 = 37.5
This means that the product owner can expect their team to complete at least 37.5 story points worth of work in the next sprint.
It’s also important to note that sprint velocity becomes more accurate over time. The more sprints they work on, the more data you receive about team performance. During release planning meetings, you’ll be able to make more accurate estimates about how long sprints take.
The Key Benefits Of Velocity Charts
Here are the two key benefits of using an Agile velocity chart:
1. Helps you make better predictions about your team capacity
Knowing the team velocity or Scrum velocity can help the product owner and Scrum master make better predictions about team capacity. It helps to better estimate if a team is capable of completing a task without facing bottlenecks.
2. Highlights issues before they become problems
Velocity numbers show the velocity of a team for every iteration.
If you see the team’s velocity dipping, they might be facing some hiccups along the way.
Their project velocity can be hampered by:
- Poor team communication: your Scrum meetings or stand-ups might not be as effective as you thought
- Low productivity: teams might be facing distractions or have technical debt, reducing their agility
- Excessive software bugs: product quality might not be up to the mark
Your team can identify these issues during their daily meetings to prevent large-scale problems that affect overall enterprise agility.
Key Limitations Of Velocity Charts
While velocity charts are essential for the Agile method, they have a few limitations:
1. Agile Velocity is not a precise unit of measure
Velocity numbers are always an Agile estimation of how much work that can be done.
It can always fluctuate due to various reasons like:
- New members joining the team
- New processes being introduced
- Changes in project scope
In the sprint planning phase, iteration velocity should only be used as a rough guideline and not a concrete measure of enterprise agility.
2. Velocity of multiple teams cannot be compared
There are no standard units for velocity. Velocity isn’t always estimated with a standard story point measure. You can use various Agile metrics like completed work or hours as a unit.
So if team A is using hours worked to measure their project velocity, team B could be using tasks completed instead. As a result, velocity is often subjective. Since each team has its own velocity units, it can be difficult to compare velocity data between multiple teams.