Posts

Sprint velocity: how to track, forecast, and stop misusing it

Illustration of a sprint dashboard with a speedometer dial and a row of rising bar charts representing story points completed per sprint, modern flat editorial style with vibrant purple and blue tones, a small agile team reviewing the chart together

Kelly Lewandowski

Last updated 07/06/20268 min read

Velocity is the easiest agile metric to calculate and the easiest to wreck. Add up the story points your team completed last sprint. That's it. The trouble starts the moment someone treats that number as a target, a productivity score, or a precise delivery promise. Velocity has exactly two legitimate jobs: helping you forecast roughly when a chunk of work will be done, and giving the team a sanity check on how much to pull into the next sprint. Used for anything else, it does more harm than good. Here's how to do both jobs well, and how to spot the misuse before it spreads.

What sprint velocity actually is

Velocity is the number of story points your team completed in a sprint. Completed means done by your Definition of Done, not "in QA" or "almost merged." Half-finished work counts for zero. A story carried over scores points in the sprint it actually finishes, not the one it started in. That's the whole definition. Velocity isn't a measure of effort, hours, or how hard people worked. It's a measure of output in your team's own story point currency, which is exactly why it only means something inside that one team.

Points are team-relative

A team's points are calibrated to that team. One team's 8 is another team's 3. This is the single fact that invalidates most velocity comparisons, and we'll come back to it.

How to calculate it (and why one number lies)

The basic formula is an average over your recent sprints: Average velocity = total points completed ÷ number of sprints Use at least 3 sprints, ideally 6 or more, and only count sprints with a roughly stable team. Here's a real-looking run of six sprints:

22, 28, 19, 31, 24, 26

Points completed per sprint

Average velocity

19–31

Actual range

The average is 25. But no sprint actually delivered 25, and the real spread runs from 19 to 31. If you plan every sprint around "25" you'll over-commit in slow sprints and under-fill in fast ones. The average is a starting point for conversation, not a contract. This is why the Sprint Velocity Calculator reports a range and a consistency score alongside the average. Paste in your last few sprints and it tells you not just the midpoint but how reliable that midpoint is. A team running 24, 25, 26 is in a different situation from one running 12, 38, 25, even though both average 25.

Forecasting: use ranges, not single numbers

This is where most velocity advice goes wrong. The classic move is "backlog ÷ average velocity = sprints to done." With a 200-point backlog and average velocity of 25, that's 8 sprints. Clean, confident, and almost certainly wrong, because it pretends your velocity has no variance. Your velocity does have variance, so your forecast should too. The simple, honest version is the three-forecast method: forecast with a conservative velocity, a likely one, and an optimistic one.

Scenario	Velocity used	200-point backlog
Conservative	Avg of your 3 slowest sprints (~22)	~10 sprints
Likely	Overall average (25)	8 sprints
Optimistic	Avg of your 3 fastest sprints (~28)	~7 sprints

Now you can tell a stakeholder "7 to 10 sprints, most likely 8" instead of a single number you'll have to walk back later. As Mike Cohn and others have long argued, a statement like "we're 90% confident this lands between sprint 7 and sprint 10" is both more useful and more defensible than false precision.

Quote a range, always

When someone asks for a date, give them two: the optimistic one and the conservative one. A range communicates uncertainty honestly and protects you when reality lands somewhere in the middle, which it almost always does.

For teams that want real probabilities, Monte Carlo simulation is the next step up. Instead of three hand-picked scenarios, it runs thousands of simulated futures by randomly sampling from your historical sprints, then reports outcomes as percentiles: a 50th-percentile (median) finish, an 85th, a 95th. "85% chance we finish by sprint 9" is a far stronger claim than any average can make. You don't need a single point estimate; you need a distribution. Illustration of a cone of uncertainty fanning out from a starting point toward a finish flag, with multiple probability paths in gradient blue and purple bands, modern flat vector style, no text or numbers

Illustration of a cone of uncertainty fanning out from a starting point toward a finish flag, with multiple probability paths in gradient blue and purple bands, modern flat vector style, no text or numbers

How teams misuse velocity

Scrum.org has gone as far as publishing a post titled "Story Points are not the Problem, Velocity is." The point sizing is mostly harmless; the damage comes from what managers do with the resulting velocity number. These are the four failure modes to watch for.

⚖️Comparing teams

Team A does 40, Team B does 25, so Team A is "more productive." Wrong. Points are team-relative, so the comparison measures nothing. It just teaches Team B to inflate.

📈As a productivity metric

The moment velocity becomes a number people are measured on, it stops measuring output and starts measuring how much pressure the team feels. Goodhart's law in action.

🎯As a commitment

"You did 30 last sprint, so commit to 30." This turns a forecast into a quota and pushes the team to pad estimates until the number is safe to hit.

🎲From a single sprint

One sprint is noise. A holiday, an outage, or one gnarly bug swings it wildly. Velocity only means something as a trend across several sprints.

The common thread: every misuse turns velocity from a tool the team uses into a target the team is judged against. Once that flip happens, the number gets gamed and you lose the honest signal you started with.

The inflation death spiral

Pressure a team to grow its velocity and it will, instantly, by quietly sizing the same work higher. Velocity climbs, nothing ships faster, and now your historical data is poisoned for forecasting. The metric you were optimizing destroys the only thing it was good for.

Velocity done right

Used as an internal planning aid and nothing more, velocity earns its keep. A short checklist for keeping it honest:

Only count work that's fully done by your Definition of Done.

Average over 6+ sprints and watch the trend, not any single number.

Forecast with ranges or percentiles, never a single "done by" date.

Re-baseline after major team changes; old velocity doesn't transfer.

Never show velocity in a slide that compares teams or individuals.

Keep the estimation conversation; the discussion matters more than the points.

That last point is the one teams forget. Velocity is a byproduct of good estimation, not the goal of it. The value of planning poker is the conversation that surfaces hidden complexity before it bites you mid-sprint. The number that falls out is just bookkeeping.

Velocity isn't your only option

If velocity keeps getting weaponized on your team, or your stories vary too much in size for points to be stable, you have options. Some teams drop estimation altogether and forecast straight from throughput. A lighter move is to keep velocity but lean on flow metrics for the parts it does poorly. Throughput (items finished per sprint) and cycle time (how long an item takes from start to done) measure delivery with real timestamps instead of estimates.

Question	Best metric
How much to pull into a sprint	Velocity or throughput
When will this backlog finish	Monte Carlo on velocity/throughput
Why is work taking so long	Cycle time and work-in-progress
Are we improving over time	Cycle time trend

Most mature teams end up using both: velocity for the sprint-level conversation, flow metrics for delivery forecasting and spotting bottlenecks. They answer different questions, and neither is a productivity scoreboard.

The bottom line

Velocity is a flashlight, not a speedometer. It helps the team see roughly how much it can take on and roughly when a body of work will finish. Point it at people instead of work and it stops telling the truth. Track it across several sprints, forecast in ranges, and keep it inside the team. When you need the numbers crunched fast, the Sprint Velocity Calculator turns your last few sprints into an average, a realistic range, a consistency score, and a backlog forecast in a few seconds. For the estimation side that feeds it, planning poker keeps the focus where it belongs: on the conversation, not the scoreboard.

At least 3 to get a rough average, but 6 or more before you trust it for forecasting. Fewer than that and a single unusual sprint skews everything. The team should also be reasonably stable across those sprints.

Only if those items were estimated in points and finished within the sprint. Many teams leave bugs and support work unpointed and track them separately, which keeps velocity focused on planned feature delivery. Pick one approach and stay consistent so your history stays comparable.

Story points are calibrated per team, so one team's 5 is another team's 13. Comparing the raw numbers measures nothing real and pressures teams to inflate their estimates. If you need a cross-team view, look at delivered outcomes or cycle time, not points.

No. Velocity measures output in a team-specific unit, not value delivered or effort spent. A team can raise its velocity without shipping anything more useful simply by sizing work higher. Treat it as a planning input, never a performance metric.