Skip to main content

How to Measure Sprint Velocity in Agile

photo of a jet engine

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.

What is velocity in Agile?

Velocity – or sprint 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.

How do you measure sprint velocity?

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:

Say you estimated story A at 4 points, story B at 2, story C at 3, and completed all three. Your velocity is 9. But if you only finished half of story A, you can’t include any of its points, and your velocity for that Sprint is 5. Scrum requires stories to fit in one Sprint. Excluding unfinished stories from velocity encourages teams to make tasks smaller in future.

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.

Why do teams measure sprint velocity?

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.

illustration of three ways velocity can help teams

Velocity helps plan your Sprints

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.

Velocity lets you visualize progress

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.

example of a burndown chart

 

Velocity gives Retrospectives a clearer focus

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:

“This Sprint we completed 21 story points. Our average velocity has been 25 story points based on the past three Sprints. That means our velocity dipped slightly this Sprint compared to last”

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.

How to improve sprint velocity?

You can improve sprint velocity by:

  • 🎓 Mastering backlog refinement. Refined backlogs contain plenty of detail. When it’s time to start a new task, team members have all the information they need to complete it. Backlog refinement often involves assigning story point estimates, which set a guide for how much effort a task involve. Backlog refinement helps teams maintain a high Sprint velocity and focus on execution because all the thinking and planning have been done in advance.
  • 🤖 Automating parts of your work process. Learn how to automate tests, generate code automatically, or use templates for specific product parts. This may take an upfront investment of effort to set up, but it pays dividends in improved velocity.
  • 👨🏻‍💻 Being aware of changes or shortcomings on the team. While you measure velocity at the team level, the performance of individual members naturally influences the number. Perhaps requirements have changed, and you’re missing a critical skill on the team, or a former top performer is going through a rough period personally, which is reflected in the team’s velocity. Keep this possibility in mind when you’re looking for ways to optimize your velocity further.
  • 🔍 Looking at outside dependencies and technical issues. When you don’t find room for improvements within the team, look at external factors that affect your velocity. Perhaps the customer doesn’t provide feedback quickly, or another department like finance has a complicated approval process for purchases the team needs. Also, review potential technical obstacles, like an old testing server that gives the team headaches and lowers velocity.
  • 🚀 Dedicating a Retrospective to optimizing velocity. Hold a Retrospective with the team when you want to find additional optimization opportunities. Maarten has a list of helpful questions you can ask during such a session, like “Was there a lot of rework on issues?” or “Did the team actually make a plan on how to deliver the Sprint Goal?”

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.

example of a velocity graph

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

Common misunderstandings about velocity

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

graph of top agile metrics

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.

Should outside stakeholders use sprint velocity for forecasting?

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:

  • 😬 It’s highly uncertain, and you’ll need to add a large buffer to your estimate. A lot of things can change during 10 Sprints that will affect velocity. Team members might leave, new items enter the product backlog, estimations might turn out incorrect, and on and on.
  • 🎯 It turns the number into an external goal instead of a tool for the team. Rarely will outside stakeholders accept something as an estimate that’s subject to change. Once given, the estimate often morphs into a hard deadline. That change turns velocity from a team-owned metric into a fixed, externally set due date that can add considerable pressure to the team or result in some form of punitive action if not met.

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.

Should I track and compare team productivity with velocity?

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:

  • ⚖️ Story points are relative units of measurement. Story Points are a “local currency” unique to your team. One story point represents a different value for team A than it does for team B. Making comparisons between teams doesn’t work.
  • 👑 The team rules the number. Even when outsiders take control of velocity, the team holds ultimate power over the number. They can, for example, inflate their estimates during Sprint Planning, cut corners in their work, or only take on simple tasks they can quickly complete to satisfy “velocity goals.”

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

Should Sprint velocity always keep going up?

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:

“Once you have your velocity, you can figure out the most important thing in Scrum: What is keeping you from going faster? What is keeping you from accelerating?”

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

“A well-functioning Scrum Team’s velocity should steadily trend upward by roughly 10% each Sprint.”

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

What’s the difference between velocity and capacity?

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.

  • 🏎️ Velocity looks at past performance to predict the right amount of work for the next Sprint. E.g. Comparing story points completed over time.
  • 🏟️ Capacity focuses on resources. It takes the velocity number and adjusts it to estimate a team’s available development resources in upcoming Sprints.

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.

When to press eject on velocity

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:

“If it’s painful to use them, if it’s a chore to fill them out, then change how you use them.”

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.

Tim Metz

Tim Metz

Tim Metz crafts content at Animalz for the world’s most amazing startups. He’s passionate about deep work and work-life balance.

Try Parabol Sprint Poker For Better Story Point Estimates

Estimate remotely with an interactive deck of cards, built-in anonymity, and two-way integrations with Jira, GitHub, Gitlab, and AzureDevOps. Sprint Poker makes estimation meetings fun, gets people talking, and helps teams craft better estimates.