Sprint velocity: How to calculate it for Agile planning

Sprint velocity is a common tool used in Agile project management. It measures how much an Agile team produces during their normal sprint cycle. In this article, we cover what sprint velocity is, how to calculate it, common mistakes to avoid, and practical tips for keeping your velocity consistent.

When measured correctly, sprint velocity can help you accurately estimate your team's workload, simplify sprint planning, and help project managers keep a pulse on their projects.

What is sprint velocity?

Sprint velocity is a metric that measures how much work an Agile team completes during a single sprint. It's calculated based on story points or backlog items completed within the sprint timeframe.

Sprint velocity is a descriptive metric, not a success metric or key performance indicator. The goal is to understand your team's capacity, not to increase it. If you treat velocity as a performance target, your team can end up overworked. Measure it consistently, but use it for planning rather than evaluation.

How to calculate sprint velocity

You can calculate sprint velocity with a simple equation:

Sprint velocity = Completed story points ÷ Number of sprints

For example, if your team completes 60 story points over 3 sprints, your average velocity is 20 story points per sprint.

Step 1: Identify completed user stories

At the end of each sprint, count only the user stories or backlog items that are fully complete. Partial work doesn't count toward velocity, as including unfinished items skews your data and makes future planning less accurate.

Step 2: Calculate average velocity across sprints

To establish your team's baseline velocity, you have two options:

1. Run an initial sprint. Start with a full sprint backlog and see how many items your team completes. The goal is to benchmark capacity, not finish everything.

2. Use estimation strategies. Try project estimation methods such as top-down, three-point, or analogous estimation to predict the output before your first sprint.

Why measure sprint velocity?

You don't measure sprint velocity just because; there are practical (and beneficial) reasons your team should measure sprint velocity. Here are a few.

• Makes sprint planning easy. For product owners and Scrum masters, knowing your team's sprint velocity can help make sprint planning easier. If you know your team's average sprint velocity, it's easier to choose the right user stories from the product backlog to move into this iteration without overloading your development team.

• Manage stakeholder expectations. If your stakeholders are asking for a timeline for a specific user story or trying to add anything before the end of the sprint, you, as a product owner, understand how that change may affect your team's output given your sprint velocity.

• Signals potential trouble. When you regularly track sprint velocity, you'll be able to measure the average velocity more consistently. If you see a sudden dip in velocity, then you know there's a potential issue, such as a roadblock like an unfinished dependency, that needs to be resolved before moving on to the next sprint.

Common mistakes to avoid when measuring velocity

Measuring sprint velocity is straightforward, but there are a few common pitfalls that can undermine its usefulness. Here are the mistakes to watch out for.

• Counting incomplete user stories. Only count work that's fully finished. Partial credit skews your data and makes future planning less reliable.

• Measuring individual velocity. Velocity is a team metric, not a personal performance score. Tracking individuals creates unhealthy competition and discourages collaboration.

• Using velocity for bonuses or performance reviews. When velocity becomes tied to rewards, teams may inflate story point estimates to appear more productive. This defeats the purpose of having an accurate planning metric.

• Comparing the velocity between teams. Every team estimates differently and works in unique contexts. A velocity of 30 for one team is not equivalent to 30 for another, so cross-team comparisons don't provide meaningful insights.

Sprint velocity vs. capacity

Sprint velocity and capacity are often confused, but they measure different things. Understanding the distinction helps you use both metrics effectively.

Use velocity to set expectations based on past performance. Use capacity planning to account for upcoming constraints, such as holidays or team members on leave.

How to visualize sprint velocity

Visualizing sprint velocity helps your team quickly understand performance and track progress. There are several project chart types to choose from:

Basic velocity chart

A basic velocity chart is a bar graph that compares projected work with actual work completed. The X-axis shows sprints, while the Y-axis displays story points or user stories. This visual makes it easy to see patterns in your team's output compared to estimates.

Burndown chart

A burndown chart estimates the amount of work your team needs to complete and compares it to the time remaining in the sprint. As the sprint progresses, the goal is for the line on the graph to move closer to zero.

If you have an estimate of your team's velocity, you can plot it on your burndown chart and see how it compares to the ideal velocity line. In the example above, you can see how early in the sprint the team completed more work than anticipated based on the ideal line.

Burnup chart

A burnup chart is the exact opposite of a burndown chart. This graph typically includes two lines: the actual work completed and the ideal goal you want your team to achieve. The ideal goal is usually a horizontal line across the graph, while the actual work will continually grow toward the goal line over time.

Tips for regulating your team's sprint velocity

Inconsistent sprint velocity often signals an underlying issue. Consistency matters because it makes your team's performance predictable and highlights problems early.

For example, if your recent sprints show velocities of 4.5, 7, 5, and 3, while the average is 6, that inconsistency warrants investigation. The goal is to keep velocity stable from sprint to sprint. Here are a few tips to help you manage your team's sprint velocity.

Clarify user stories

One way to stabilize your team's sprint velocity is to ensure user stories are clear and easy to understand before the sprint starts. A user story is a brief description of a software feature written from the end user's perspective.

These user stories are often attached to items in a backlog. This ensures that Scrum or project team members can focus on the work they need to do, rather than spending time hunting down stakeholders for more specifics.

Ensure consistency

If your team's velocity is inconsistent, you might be changing too many variables from sprint to sprint. For example, are you swapping different team members from your development team? Team composition can affect how much work your team can accomplish.

Here are a few other variables that may affect your sprint velocity:

• Sprint length

• Increase in story points

• Change in processes

Establish a uniform definition of "done"

It's important that everyone on your team has a clear understanding of what it means for a user story to be "done" or complete. This is a key aspect of the Scrum framework that is also used in other Agile methodologies.

When your team has a clear definition of what it means for a user story to be complete, they can more accurately estimate the work involved in each one. This, in turn, leads to more accurate sprint velocity.

Host a sprint retrospective

One of the benefits of the Agile methodology is its iterative development process. At the end of each sprint, there's an opportunity to reflect on what went well and what didn't.

A sprint retrospective meeting is dedicated to reflecting on the past sprint and how to improve for the next one. The goal here is to continuously improve by applying learnings from past sprints into future sprints.

Track sprint velocity with work management software

Measuring sprint velocity is most effective when you have a single source of truth for all your project data. With a work management platform like Asana, you can:

• Track deliverables and manage your product backlog in one place

• Visualize velocity trends without switching between tools

• Spend less time on manual reporting and more time acting on insights

• Give stakeholders the visibility they need to stay informed

Ready to bring clarity to your Agile projects? Get started with Asana today.

Frequently asked questions about sprint velocity