How to calculate sprint velocity

Working with the Agile methodology can boost productivity, improve quality, and get the product in your customer’s hands faster than any other approach. The key to this workflow lies in good planning, execution and constant improvement.

Before diving headfirst into a sprint, it’s helpful to hold realistic expectations for what your team can do in the amount of time available. This will give you a better idea of how many sprints will be required before finalizing the product and gives you a predictable roadmap. Setting expectations in the early stages makes a development cycle easier for everyone involved.

But how do you find out this information in advance? How do you make sure all your resources are being used effectively, with the right team members in the right place? Let’s take a look at how to calculate sprint velocity when working with Agile/Scrum methodology.

How to calculate sprint velocity

Essentially, sprint velocity is the measure of how much you can realistically accomplish within a sprint cycle. To work this out, you need to look at what your team accomplished on previous sprints. Consider how long the sprint lasted and the volume of work completed.

The velocity is worked out by taking the number of units of work completed over several past sprints, and dividing by the number of sprints. The actual unit of measurement can vary depending on how your team works. You could use hours, tasks, or whatever you use to estimate workload.

The average number of tasks or hours logged per sprint is your sprint velocity.

Let’s look at a couple of examples.

Calculating sprint velocity using tasks as a measure

For this example, let’s look at 3 past sprints.

Sprint 1: The team planned for 8 tasks to be completed, but only completed 5 of those tasks.

Sprint 2: The team planned for 4 new tasks to be completed and finish the 3 left over from sprint 1. 7 tasks were completed during sprint 2.

Sprint 3: The team planned for 6 new tasks to be completed, completing all 6 tasks.

So, over the three sprints, 18 tasks were completed overall (5+7+6), but the workload was inconsistent and the first sprint fell way short of completing all tasks assigned.

In order to make the workload more consistent and easier to manage for the team, we need to try and set realistic targets. This is where sprint velocity comes into play.

Calculating the sprint velocity:

18 tasks completed over 3 sprints would divide into 6 tasks per sprint, making your sprint velocity 6 tasks.

Setting a target of 6 tasks per sprint would mean that the team is much more likely to achieve this target on each sprint. In this example you would avoid possible pressure and de-motivating effects from your team failing to complete 3 out of 8 tasks (an unrealistic expectation when we look at the average Agile velocity).

Calculating sprint velocity using hours as a measure

This is similar to the last example, but we’ll be translating the tasks into hours.

Sprint 1: The team planned for 8 tasks to be completed in 160 hours, but only completed 5 of those tasks in that time.

Sprint 2: The team planned for 4 new tasks to be completed and finish the 3 left over from sprint 1. 7 tasks were completed during sprint 2 in 240 hours.

Sprint 3: The team planned for 6 new tasks to be completed, completing all 6 tasks in 180 hours.

Over the three sprints, the team put in 580 hours, but there was a crunch during sprint two that we need to avoid. So, let’s work out the average hours per sprint and use that as the target going forward.

Calculating the sprint velocity: 580 hours completed over 3 sprints would roughly divide into 190 hours per sprint, making your sprint velocity 190 hours.

This approach allows for more flexibility with complex projects as longer tasks can be accommodated without dragging your average task velocity down. You can also combine these two methods to create targets both tasks and hours completed per sprint — whatever works best for your team.

How to use sprint velocity

Agile velocity calculation should be used during the planning stages. It will help when assigning roles to team members, assist in allocating resources so every task has what it needs and most importantly, it will help make sure your team is working at full efficiency without risking burning your team out.

Looking back at the first example we used, a Scrum Master now knows that the ideal number of tasks per sprint is 6. So, going forward they will plan for 6 tasks per sprint to ensure consistent and effective workflow.

The best way to track your sprint velocity is with visual aids. Even a simple Kanban board – such as this one from EasyRetro – makes it simple for a Scrum Master to track the team’s progress. Once the sprint velocity has been worked out, create cards for each task and within seconds you have a clear view of the upcoming sprint that anyone can understand at a glance.

Advantages of using sprint velocity

For a team already using Agile methodology, incorporating sprint velocity can make a huge difference to how you manage projects and assign staff.

Because sprint velocity uses real data from your previous sprints, rather than just guesswork, you can create highly accurate roadmaps to project delivery. This benefits all stakeholders inside and outside the business.

As you have already seen, it’s not a difficult, time-consuming process either. The easy-to-use formula makes it quicker and easier to estimate timeframes and find efficiencies to shorten them. If you’re relying on external clients, this means less work for your team before securing contracts, meaning more profit at the end of the project. Of course, if your project is an internal effort, working out your sprint velocity is just another way using EasyRetro can save you, your team and your business time and money.

It’s not all about the money though. Setting sprint velocities encourages the team to think forward and offers a target for the team to work towards. Deadlines can be stressful, but carefully planning ahead ensures your team works smart and hard. As sprint velocity becomes a key metric in your process, you’ll find that crunch towards the end of your sprint cycles is reduced, and workflow is more consistent.

Challenges of using sprint velocity

As helpful as sprint velocity can be, it’s not without its drawbacks.

We may be approaching “normal” life again, but remote work is here to stay. Sprint velocity calculations can be less accurate for remote teams. There are so many variables that are introduced with remote working, from distractions at home to internet connectivity issues.These variations need to be accounted for, making your sprint velocity figure more of an approximation than an accurate prediction.

Another issue is that using “tasks” can be too vague a measure of work. Creating an entire UX from scratch could be summed up as a single, big task, or you could break it up into multiple, smaller tasks. However, when calculating sprint velocities, you treat the task as if they were the same size and complexity.

For example, if a task in sprint 1 took 200 hours and another task in sprint 2 only took 20 hours, when it comes to calculating velocity, the result wouldn’t factor in how much time either of those tasks actually took, throwing off your future calculations. Make sure you use the right approach for your team and your workflow.

EasyRetro makes tracking sprint velocity even easier

Now you know the ups and downs of sprint velocity, you’re probably wondering about the best way to implement it in your future projects. Thankfully, EasyRetro has your back.

Our Kanban board templates are perfect for tracking your sprint velocity and we have a huge range of them available to get you started. So, what are you waiting for? The first board is on us!