The velocity is a simple, yet very important metric that Scrum teams use to predict how much work can be actually completed within a sprint. It can be used to work out time estimates during the planning process, and helps the teams to track and improve their efficiency over time.
In this article, you will understand what sprint velocity is, how it is calculated, and how the team can track their progress using a velocity chart.
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totalling the Points for all fully completed User Stories. - Scruminc
As a key performance indicator, the velocity measures the speed of a development team, and is an indicator of the average amount of PBIs (Product Backlog Items) or User Stories that can be completed during a sprint.
Release Planning is done based on the team’s predicted velocity. The Product Owner uses the velocity calculation as a rough estimate to determine how many sprints will be needed to finish all the PBIs that are in the Product Backlog, and to achieve an MVP (Minimum Viable Product) that is ready to be shipped.
Here’s an interesting point to note! While most Scrum teams estimate velocities using user stories, story points and burndown charts, the Scrum Guide itself does not have much to say on the subject. All that is mentioned is that estimates should happen, and the nitty gritty of how, exactly, it is done is left to each team to decide for themselves.
Story points are estimates of effort as influenced by the amount of work, complexity, risk and uncertainty. – Mike Cohn, Mountain Goat Software
Story points in Agile measure the effort and time it will take to complete a user story, or any other piece of work. Story points are relative; for example, a story that is assigned a 2 should have approximately twice the complexity or should take twice the time estimated for a story point with the value 1. Story points are ratios, which are decided by the team, and should be in whole numbers for easy handling. They could decide to have story points in multiples of 10 instead of multiples of 1; say 10, 20 and so on.
Story points need to take into consideration how complex a task is, how much risk and uncertainty there is around it, and the amount of work required to complete entirely.
Each Scrum team has its own velocity, which is based on the individual capacities of each team member. If the team members change over the course of the project, which ideally should not happen (but at times cannot be helped), the velocity will change. Here, we will show you how velocity can be calculated, provided all other parameters stay constant.
Typically, velocity is calculated based on the work that has previously been done. If a team is new, the velocity for the first sprint is roughly calculated during the first sprint and is fine-tuned and rendered more accurate during subsequent sprints. A good average would require a review of at least three sprints.
This example uses story points for the estimate.
Once a sprint is completed, the team sits together for the Sprint Review event. The number of story points that were successfully completed is summed up. Any incomplete story points are moved to the next sprint.
Let’s assume that…
During sprint 1:
The team made a commitment to completing six user stories. Each story was estimated at six story points, which made a total of 36 story points. However, one of the story points was not completed. This means that they completed 30 story points.
During sprint 2:
The team made a commitment to completing seven user stories, which included the one that was previously left incomplete. Again, each story was estimated at six story points, which made a total of 42 story points. They were able to complete six, which adds up to 36 story points.
During sprint 3:
The team made a commitment to completing nine user stories. Each story was estimated at six story points, which made a total of 54 story points. They were able to complete only seven out of nine which adds up to 42 story points.
All that has to be done is to add up the total of completed story points, and divide by the number of sprints.
So, your average sprint velocity is 108 ÷ 3 = 36.
Future velocity can be calculated based on this figure. Let’s assume that there are another 360 story points left to be completed during the entire project. This will require another 10 sprints, roughly. If each sprint takes 2 weeks, then the PO can safely assume that the product will be shipped after 20 weeks.
Elements that can throw this estimate off balance include changes in team size, or changes in the project scope or complexity. Agile is, after all, flexible and there will be variations between sprint to sprint.
Agile teams use metric-tracking tools, such as velocity charts, Kanban boards and burndown charts as a visual representation of the progress of work. As these charts are shared and updated in teal time, they allow anyone to access and view them at any time.
A velocity chart is a very simple chart that shows story points on the vertical axis, and the completed sprints on the horizontal axis. As a visual representation of the status of a project, it shows estimated story points against actually completed story points.
Source: Velocity Chart
A velocity burndown chart shows the team’s progress toward completing all the work for a project. The team can easily see how much work has been completed, as against the total quantum of work left to be done. They can also judge how much time has elapsed, against the time that is left. When all the work is completed, the chart ‘burns down’ and shows both the time left, as well as the work left, as zero.
Source: Velocity burndown chart
To sum up
Velocity is one of the most important metrics in any Agile strategy. As the project progresses, the Product Owner can easily see whether the work progress is on track. If the velocity is very slow, they could consider adding extra team members and other resources to speed up work and ensure that goals are met. Velocity is an indispensable metric and is one that every Agile team should follow to boost productivity and achieve success.
Leave a Reply
Your email address will not be published. Required fields are marked *