Breaking down projects into sprints gives your team a clear short-term focus.
In the previous article, we looked at the Sprint Velocity Best Practices. But how do we measure our velocity to know how long each sprint is going to take and plan ahead?
In this guide, we’re going to dive into:
The Agile management framework is based around sprints — short periods of work, moving towards a specific goal.
Sprint velocity measures the amount of work your scrum team can complete within the average sprint.
There are several different ways to count sprint velocity. You could find the average number of story points, the average hours of work done, or even the number of ideal days. The higher the score, the more your team is getting done.
When you create a roadmap for developing your product, it’s common to set a target date for each major stage. But how do you know what is achievable?
Sprint velocity helps you estimate what you can feasibly get done within each sprint, and how many sprints it will take to reach bigger goals. In turn, this can inform your estimated delivery dates.
Sprint velocity metrics are also very informative when it comes to productivity. By tracking the velocity of your team over time, you can see whether you are becoming more efficient or spending too much time comparing notes on the latest Wordle.
While sprint velocity is based on data, it’s more of an estimate than a hard figure.
To come up with a meaningful number, you need to track the amount of work done in at least five sprints. Then, you can plug your data into one of these sprint velocity formulas:
Measuring sprint velocity via story points is a good idea, because these units take into account the complexity of work done, not just the time spent on the job.
To find your sprint velocity, add up all the completed user stories within each sprint. Then, multiply this figure by the number of story points required for each user story:
5 user stories × 8 story points = 40 story points (Total)
In this case, the team completed five user stories. Each of those user stories involved eight story points’ worth of work.
To find your sprint velocity, repeat this process for multiple previous sprints and then find the average:
Sprint 1: 36 story points
Sprint 2: 40 story points
Sprint 3: 38 story points
36 story points + 40 story points + 38 story points = 114 story points
114 story points ÷ 3 sprints = 38 story points/sprint (average)
In this case, your sprint velocity is 38 story points per sprint on average. Not bad!
If you prefer to use a more traditional metric, you can just as easily calculate sprint velocity in hours.
In this case, find the number of hours your team spent on each sprint:
Sprint 1: 360 hours
Sprint 2: 356 hours
Sprint 3: 400 hours
Then, add all your hours together and divide by the number of sprints to get your average sprint velocity:
360 hrs + 356 hrs + 400 hrs = 1,116 hours
1116 hours ÷ 3 sprints = 372 hours/sprint (average)
For more granular statistics, you can perform the same calculation to find sprint velocity per story.
An alternative method for measuring sprint velocity is using ideal days. This option is better suited to analysing the performance of individuals, rather than the performance of your entire team.
The calculation for this metric builds on the one mentioned above. First, you need to find out how many hours were completed in each sprint. Next, you need to divide the number of hours of work completed by the number of hours in an ideal day.
Sprint: 42 hours
Ideal day: 8 hours
42 hrs ÷ 8 hrs = 5.25 ideal days
Finally, we can add together the number of ideal days completed in all the sprints, and divide this figure by the number of sprints.
Sprint 1: 5.25 ideal days
Sprint 2: 4.5 ideal days
Sprint 3: 6 ideal days
5.25 ideal days + 4.5 ideal days + 6 ideal days = 15.75 ideal days
15.75 ideal days ÷ 3 sprints = 5.25 ideal days/sprint (average)
If you don’t want to run though the numbers yourself you can plug your data into this free sprint velocity calculator.
So far, we have looked at how you can estimate your sprint velocity from recent sprints. However, this figure only becomes truly useful when you have something to compare it with.
Here are two common ways that Scrum teams track their sprint velocity over time:
Perhaps the easiest way to track your productivity is with a sprint velocity chart. This is a simple graph that shows how your average changes over time.
To add some extra context, you can also include the expected amount of work for each sprint. This will reveal whether your team is consistently hitting expectations, or falling short. It will also give you a sense of how to adjust your future estimated workloads.
When you’re on a tight deadline, you might want to keep an extra close eye on your sprint velocity.
Burndown charts show you how much work you have completed, how much work is still outstanding, and how much time you have left to get it done.
While this option is a little more complicated to set up, it provides a really helpful overview for project managers. In one glance, they can clearly see if the team is on schedule or lagging behind.
Technical debt is the silent velocity killer. To measure sprint velocity, you need to ensure that you know your codebase problems well.
Track and prioritise your technical debt regularly to see which parts of the code can be problematic and will affect your team's velocity.
The easiest way to do it is to use the Stepsize VSCode and JetBrains extensions. They’ll help your Engineers see issues in the codebase and report them directly from their editor reducing context switching.
The main goal of measuring sprint velocity is to plan future sprints and report estimations, not measuring your team's performance. As Goodhart’s says, “When a measure becomes a target, it ceases to be a good measure.” So don’t compare your teams’ velocity and find other metrics for your team performance.
Make quality of your code your main focus. When you feel like you should be getting more done in the week, a natural reaction might be to increase your working hours.
While this may work for an individual sprint, it’s not going to provide long-term improvement. It can also lead to burnout in your team.
Try to focus on quality. Encourage your team to get things right the first time, even if it takes a little longer. In the long run, this will actually save a lot of rework and improve your code quality.
As we have discovered, sprint velocity is an important metric. There are many different ways to measure it, and even more ways to improve it.
Here’s what we have learnt:
Follow these steps, and you might be surprised just how much your team can get done in your next sprint!