Sprint Velocity: How to Calculate Velocity in Agile

Ajet’s cockpit is packed with instruments and gauges that give pilots the information they need to fly an aircraft safely and effectively. The artificial horizon, airspeed indicator, altimeter, turn coordinator, heading indicator, and vertical speed indicator all provide critical data. And those are just the core flight instruments.

But while some metrics – like altitude – are more important than others, a pilot never relies on one metric alone to fly a plane.

Scrum teams also have many instruments and metrics available to guide their work. Many fixate on just one: Sprint velocity. But focusing on one metric without paying attention to other indicators can lead teams into a nosedive or burnout. Just like pilots who forget to check their fuel levels.

This article explores how velocity can benefit your team. But also why people sometimes misunderstand – or even abuse – this agile metric.

👻 Psst! If you’re new to Agile or need a refresher on specific terms, pull up this handy Agile glossary in another tab, and refer to it as needed.

Velocity is the number of story points completed by a team in one Sprint. Some teams use different measurements, like hours or stories completed, to calculate their velocity. Whatever data you use, the concept remains the same: Velocity indicates how much work the team has finished in a Sprint.

Teams calculate velocity at the end of each Sprint. Simply take the number of story points for each completed user story during your Sprint and add them up. Your velocity metric will be the absolute number of story points your team completed.

For example:

Velocity is measured at the team level and never for individuals. That’s because optimizing team performance outweighs the benefits of optimizing individual performance. While this is not explicitly stated in the Scrum Guide or Agile Manifesto it is an implied tenet of both.

Velocity can help teams make more accurate plans for their Sprints. That’s because it helps teams understand how many story points they can generally complete in one Sprint. The number can also serve as a conversation starter when you set the stage in your retro meetings or be a warning signal for teams to investigate.

During Sprint Planning, you can use velocity to calculate how much work you can reasonably take on for one Sprint. Many teams find value in calculating their average velocity over the past three Sprints. This can then serve as a cap for the number of story points bookmarked for the upcoming Sprint.

Say your average velocity over the past three Sprints was 9 story points. In that case, the story point sum of the items you’re selecting for the upcoming Sprint shouldn’t exceed that number.

Velocity sets the expectation in Sprint Planning for how much work your team can complete. But it’s not a fixed limit. If teams end up exceeding velocity, that’s fine. For example, it’s likely to happen as new teams have more and more experience working with the codebase or alongside one another.

Many teams also find value in visualizing average velocity as a downward line on a Burndown chart. Burndown charts help teams get a clearer picture of what delivery looks like across the Sprint. Are story points gradually completed over the Sprint or is there often a rush towards the end? 

By comparing actuals versus your “ideal burndown” line you can see if you’re on track or falling behind.

You can use velocity during Sprint Retrospectives to signal potential issues or measure the effectiveness of changes you’ve made to your work process. It’s a great way to set the stage at the beginning of a retrospective:

For example, a retrospective facilitator may say:

If your velocity fluctuates heavily between Sprints it could signal your user stories are too large. In that case, you may need to do more story splitting to cut them up into smaller pieces of work. But it could also signal burnout, blockers, or other process issues that need debugging in your retros.

Say the number of bugs in your team’s work has started increasing recently. That could signal the team is working too fast, completing many items without sufficient testing. In that case, you may want to aim for a lower velocity (yes, slowing down!).

The expected result of slowing velocity is fewer defects in the Sprints ahead because the team takes more time for code reviews, tests, and other quality checks. A lower velocity in this case may result in a more healthy Escaped Defect Rate – another popular Agile metric.

In Scrum, user stories should fit within one Sprint and ideally be capable of completion in one day at most. When they don’t, you may find that teams make progress on a story but can’t add its points to the current Sprint’s velocity since they didn’t finish the item, causing fluctuations in the metric.

You can improve sprint velocity by:

During a team’s initial Sprints, for example, velocity will almost certainly fluctuate heavily. You’re still calibrating estimates, meetings take longer, and developers may be unfamiliar with the codebase, so there’s less time for execution as people figure out how to collaborate effectively.

(Graphic adapted from Maarten Dalmijn)

That’s why it’s critical to only start relying on and expecting a relatively stable velocity after three to five Sprints. Optimizing velocity during this period would be ineffective and irrelevant. You simply won’t have enough reliable data for the metric to be meaningful.

Maarten Dalmijn, Head of Product at Rodeo and Serious Scrum ambassador, recommends you make everyone aware of this initial variability in advance. Managing expectations prevents stakeholders from losing their belief in Scrum. It also protects the team’s motivation.

You also want to make sure you set the right objective for your optimization efforts. Aiming for increased velocity makes sense if you’re focused on productivity gains. But a lower number might be better when you want to improve the quality of work, like in the earlier example of reducing bugs.

The paradox of velocity was neatly illustrated in a survey we ran on Agile metrics. Survey respondents ranked it as the second most popular metric, but it was also the metric most commonly mentioned as unhelpful. 😯

(Source: The 10 Most Helpful Agile Metrics According to Experts)

Velocity can help or hurt your team, depending on how – and by whom – it’s deployed. Below, we answer four questions about Sprint velocity to clarify common misunderstandings and abuses.

Sometimes, Product Owners (POs) use velocity to make forecasts to stakeholders about Sprint, feature, or project completion. Say the total number of estimated story points for your project adds up to 100, and your average Sprint velocity is 10. Then you could forecast that it will take you 10 Sprints to deliver the project.

There are two issues with using velocity in this way:

Note the difference between this way of using velocity versus the team’s use we discussed earlier of setting a cap during Sprint Planning. Forecasting, as in this example, only serves external stakeholders, whereas using Velocity as a cap or the limit of what can be achieved, helps the team plan their Sprints more accurately.

Velocity is an unreliable metric for tracking team productivity. Using the number in that way also conflicts with the fundamental agile principles of delivering customer value and trusting teams to self-organize and get the job done.

Velocity makes for a lousy performance metric and turns into “measurement theater” for several reasons:

Agile’s basic premise is that delivering customer value early and often matters most and that a self-organizing team knows best how to do that. As long as the team hits their Sprint goals and produces customer value continuously, how they do so is their business and should certainly not depend on their velocity, a number that says little about value delivered, especially when viewed in isolation of other Agile metrics.

Maarten sums it up aptly with the title of one of his articles: “Companies That Obsess Over Velocity Are Clueless About Scrum.”

Whether Sprint velocity should always increase depends on whom you ask.

Scrum co-creator Jeff Sutherland is pretty clear on this point. In his book, Scrum: The Art of Doing Twice the Work in Half the Time, he writes:

If that’s not explicit enough, his website states that:

But many agile practitioners, like Maarten Dalmijn, the experts we surveyed, and John Cutler, who coined the term “feature factory,” don’t share this view. They argue that an obsession with velocity can lead to lower quality work, product features with little customer value, or team members burning out.

Common sense alone shows that higher velocity isn’t always the appropriate goal and that it cannot keep increasing into infinity. Reducing velocity naturally serves any situation where slowing down might increase quality, value delivered, or team happiness.

So, to return to our question: Should Sprint velocity keep going up? We’d say, “often, but certainly not always, and only for the right reasons.”

Velocity and capacity are both agile metrics, but they often get confused. Both are used to measure and predict how much work a team can complete, but they do so differently.

For example, You have a team of just two developers whose average velocity is 10 story points. One of them will be on vacation for the entire next Sprint. In that case, you have 50% fewer developers, so your capacity for the next Sprint would be 5 story points.

Velocity is an optional measurement to help Agile or Scrum teams team reach their Sprint Goals. The team should own it, track it, and decide whether or not it’s helpful for their work.

Allie Dyer Bluemel at Shortcut provides a helpful gauge for metrics like velocity:

When it comes to velocity, you and your team are the ones flying the plane. Nobody else is in the cockpit, except perhaps a Scrum Master. Your attention is on the Sprint Goal. So you cross-check the velocity meter when necessary. The PO at air traffic control keeps you updated on your end destination.

In this metaphor, outside stakeholders are like the executives at airline HQ. They keep an eye on fuel costs and passenger numbers. They’d never radio into your cockpit to inquire – or lecture you – about your flight instruments. If your managers do, it might be time to press eject on them, velocity, or both.