Measuring Sprint Velocity: Formulas & Mistakes to Avoid🙅 (2023)

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?

Now we’re going to dive into:

• What is sprint velocity?
• What formulas you can use to measure it?
• 3 mistakes to avoid when measuring sprint velocity

What Is Sprint Velocity?

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.

Why Does Sprint Velocity Matter?

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.

How Do You Measure Sprint Velocity?

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:

1) Sprint Velocity in Story Points

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!

2) Sprint Velocity in Hours

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 hoursSprint 2: 356 hoursSprint 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.

3) Sprint Velocity in Story Points and Ideal Days

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 sprint velocity calculator.

What Is the Best Way to Visualise Sprint Velocity?

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:

1) Sprint Velocity Chart

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.

2) Sprint Velocity Burndown Charts

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.

3 mistakes to avoid when measuring sprint velocity

1) Not taking technical debt into account

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 velocity.

The easiest way to do it is to use the Stepsize VSCode or JetBrains extensions. They’ll help your Engineers see issues in the codebase and report them directly from their editor reducing context switching.

2) Using velocity to measure the performance of a team

The main goal of measuring sprint velocity is to plan future sprints and report estimations, not measuring your team 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.

3) Focusing on the numbers too much

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.

Take Control of Your Sprint Velocity

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:

• Sprint velocity is a good measure of productivity
• You can measure it in story points, hours, or ideal days
• It’s best tracked using regular charts or burndown charts
• To improve your sprint velocity, focus on quality and not quantity

Follow these steps, and you might be surprised just how much your team can get done in your next sprint!