Sprint velocity was briefly mentioned in our last blog post about sprint release planning. In this post we will explore it in further detail.
Velocity is a key metric in Scrum, which accurately measures how much work a project team can complete within a sprint. It can be measured in a number of ways, depending on the unit of measurement being used in the project. Most typically, it is measured in man-hours, story points or number of tasks.
The power of velocity is that the unit of measurement can be calculated daily, across the course of a week. This can then be used to accurately estimate how much work can be completed over a longer time-period.
Measuring Velocity
Only completed work is included in the velocity calculation, partially-completed user stories do not count, no matter how close they are to being marked as “done”. For example: if the team identify 20 user stories in their first sprint, but only complete 14 of those, their velocity for that sprint will be 14.
One sprint however, doesn’t give a true indication of the sprint velocity. The team may have overestimated how many user stories they can complete in a given time-frame. They may have completed 14 user tasks but be very close to completing all 20. To gain an accurate representation the velocity must be measured across a number of sprints and then averaged.
If in the following sprints the team complete 18, 22 and 16 tasks, their sprint velocity can be calculated as 17.5.
The velocity can also be used as an indication of how long it will take a team to complete a project. If there are 70 user stories, then it can be estimated that the project will be four sprints long.
This gives a much more accurate picture for future estimations and allows the team to make educated guesses about what they can deliver going forward.
The Burndown Chart
Also referred to as the Scrum Velocity Chart, the Burndown Chart provides a visual representation of the sprint velocity. Taking the form of a traditional bar chart, the number of days in the sprint are plotted along the x-axis, whilst the work remaining makes up the y-axis.
At the end of each day the work remaining will be plotted, leading to a slope in the chart towards zero. This slope can help the scrum master predict the outcome of the sprint and the x-axis can be moved to identify whether the predicted user stories will be completed on time, ahead of time, or later than anticipated.
Limitations
Whilst velocity can provide somewhat accurate estimations, it is important to remember that that is what they are. Estimations.
Whilst it can give a sound, overall picture of the team’s performance, it lacks the context to make really good predictions, and should therefore be used in conjunction with other information.
Velocity is also most effective when used with established teams, as frequent changes in personnel make the calculation less meaningful.
How to improve sprint velocity
Although a goal of the team may be to increase sprint velocity, it is important to remember that speed is not the be-all and end-all. Being pushed to deliver work faster can result in a decrease in the quality produced and so rather than focussing solely on speed, consider the following.
Increase the quality
The initial reaction to increasing quality is, “won’t that decrease sprint velocity?”.
In fact, increasing the quality of work will pay dividends further down the project line, producing less issues and allowing the team to move at a higher velocity.
Optimise sprint planning meetings
Although agile isn’t designed to be planned too far in advance, important efficiencies can be gained by some advance planning.
It is a good idea in sprint planning meetings to plan a few sprints ahead, with the next one to two sprints planned in detail, and the following sprints outlined with user stories. The team will be able to see the bigger picture and dependencies and challenges can be identified in advance, allowing the team to consider their approach.
Following through with sprint retrospectives
At the end of every sprint, a retrospective should be held to discuss what went well and areas for improvement. This can however, be neglected or turned into a venting session where problems are presented without being concluded.
Sitting down as a team and identifying any problems can help the product owner find practical solutions, and thus speed up velocity.
Identify training needs and additional resources
It is important to identify if the team has any skills gaps, and, if any are found, to provide appropriate training or supplement the team with additional staff who have those missing skills.
Some issues with velocity can also be improved by providing better tools or infrastructure to help the team solve problems and move more quickly.
Agile Sprint velocity is an important metric used in estimation. In a stable team it can be used to identify how many user stories can be completed in a sprint, and thus how long a project will take to complete. It must be acknowledged however, that although it is an important metric, it must be used carefully and in conjunction with context.
