How to Calculate Sprint Velocity in Agile Software Development

When running sprints in a scrum process, it’s important to ensure your team stays on target.

It may seem natural to change priorities immediately in response to incoming requests. However, if it’s not scheduled until the next sprint, you may be forced to wait until then to complete it. While that may seem contradictory, it’s a crucial part of ensuring your team stays on schedule and there’s ample time to complete planned tasks in projects.

So, how do you ensure your team stays on target in each sprint? Calculating sprint velocity in the scrum agile process is key.

Here’s what you need to know about calculating sprint velocity in a scrum agile framework.

What Is Sprint Velocity?

If you’re wondering how to calculate velocity in scrum, it’s pretty straightforward.

Sprint velocity is a way of measuring the amount of work done in a given sprint.

It’s essentially the mean or average number of tasks logged (typically measured in story points) per sprint.

Why Is Sprint Velocity Important?

While calculating sprint velocity may seem tedious, it is important because it helps you track your team’s capacity to complete work.

This has a few benefits:

• Ensure your team is staying on target with project goals.
• Identify where projects are lagging and help prioritize certain tasks.
• Help give an estimate of what your team can accomplish in a given sprint.

How to Calculate Your Sprint Velocity

In software development, calculating scrum or agile velocity is quite simple. Once you know the formula, there are a few key things to keep in mind when measuring story points and calculating sprint velocity.

Note: While many teams use story points to determine how much time and effort a project element takes, you can also use the number of tasks, hours, or another metric.

The Formula

When figuring sprint velocity, estimate each piece of work, and add up the completed work at the end of each sprint. Again, this is typically measured in story points. Then divide the total number of story points completed in each sprint by the total number of sprints.

In short: Figure the number of tasks completed per each sprint, add the total, and divide it by the number of sprints.

For example:

• Sprint 1: 6 story points completed
• Sprint 2: 4 story points completed
• Sprint 3: 8 story points completed

Your sprint velocity would look like this:

6 + 4 + 8 = 18 18/3 = 6

Therefore, your sprint velocity would be 6.

However, it’s not always that simple. What happens if developers have different definitions of what “done” means on individual tasks?

To ensure you accurately calculate sprint velocity, here are a few other tips to help.

1. Ensure Each Ticket Is Clearly Defined

Ensuring each ticket has a clear definition of what “done” means and when each task is complete will help ensure you get the most accurate sprint velocity possible.

If a developer marks a ticket as “done” when they simply accomplished half of a 2-point task of a sprint, that doesn’t help your sprint velocity estimates. It can throw off your workflow — not just in your department but across company departments as well.

Tasks that were marked as “complete” when they’re actually incomplete can pile up on upcoming sprints, throwing off your team planning and causing other project elements to fall behind.

Be precise enough, and ensure that the ticket is small enough that there is no room for ambiguity. This will help ensure your calculations of your team’s overall velocity is as accurate as possible.

2. Identify Dependencies and Work Around Them When Possible

In agile development, one issue you may run into is when you want to complete a task, but you’re not scheduled to do it until the next sprint because it’s dependent on other tasks in the first sprint.

This can cause conflicting problems:

• If you decide to work on the task in the first sprint instead of waiting when it’s scheduled in the second sprint, that takes away from the time and work capacity scheduled for the first sprint. This can mean that tasks initially scheduled for the first sprint don’t get done, or they are completed late.
• If you break the sprint and add in the task, it can solve immediate problems — saving you time and energy in the long run. However, this can still alter workflows.

If you end up needing to adjust the tasks done in a sprint, make sure you remove other tasks accordingly so that the velocity goal remains roughly the same. See if tasks need to be shuffled around and if some can be saved for a later sprint to continue maximizing efficiency.

How Does Sprint Velocity Measure Efficiency?

• Evaluates workload
• Tracks team predictability and consistency
• Identifies if targets and goals are being met
• Keeps teams accountable in following a schedule and prioritizing tasks

Comparing the goaled number of tasks completed per sprint compared with your sprint velocity can show if your team is estimating and working effectively.

Here’s an example using our previous scenario:

• Sprint 1: 6 story points completed
• Sprint 2: 4 story points completed
• Sprint 3: 8 story points completed

Let’s say your software development team aimed to have 7 story points completed per sprint.

The velocity of Sprint 3 would be above target. Sprint 1 nearly hit the mark, while Sprint 2 fell far short.

With a sprint velocity of 4, that would mean your team’s sprint velocity is likely falling short.

Using this data, you can evaluate where there are inefficiencies in your team’s productivity and workflow:

• Are there too many dependent tasks in each sprint?
• Are tasks not clearly defined?
• Were developers marking tasks as completed when they weren’t finished, indicating definitions aren’t clear enough?
• Did team members pick up tasks that were scheduled for a later sprint?
• Are developers systematically misestimating certain types of work?

The Bottom Line

Calculating scrum velocity is a straightforward way to help ensure your team is staying on top of projects they need to.

It’s a great metric to help identify if your team is predictably completing tasks in each sprint and can help reveal when and where development is running into unexpected roadblocks.

If you’re looking for a tool that makes it easy to track sprint velocity and overall productivity, minware evaluates the full software development lifecycle and empowers your team with analytics. Learn how much work really goes into each task and identify tasks that have stagnated or been abandoned.

When your teams are empowered with the right tools and data, you can ensure you’re effectively delegating work, prioritizing tasks, and making the system as efficient as possible.