Sprint velocity: how to actually measure it (and where it lies to you)

Velocity is the amount of work a team completed in a sprint, measured in whatever unit they estimate in — usually story points, sometimes just issue count — averaged over several recent sprints to smooth out the noise of any single one. Its only legitimate job is forecasting how much a team can realistically commit to next sprint. The moment it starts getting used to compare teams, judge individuals, or answer 'are we getting faster' as a management question, it's being asked to do something it was never built to measure.

The actual formula

Sum the story points of everything the team completed in a sprint — completed, not started or in progress — and do that for the last three to five sprints, then average them. Three to five is a deliberate range: fewer than that and one unusual sprint swings the number too far; more than that and you're averaging in team composition or process changes that make the older sprints not representative of the team today. If a sprint was unusual — someone was out for half of it, a production incident ate two days — note it and consider excluding it rather than letting it silently drag the average in a direction that doesn't reflect normal capacity.

A worked example

Say a team closed 18, 22, 15, and 21 points across four recent two-week sprints. The trailing average is 19 points. If they're planning the next sprint and pull in issues totaling 19 points, they're committing to something consistent with recent reality rather than optimistic guessing. If the 15-point sprint happened because two engineers were at a conference for a week, it's fair to note that and lean the plan slightly higher than a naive average — but the correction should be explained, not just applied by feel, or the number stops being a forecast and becomes a mood.

The three ways it lies

Point inflation is the quiet one. If a team starts feeling pressure around velocity, points creep upward for the same actual work — a task that would've been a 3 six months ago is now a 5 — and the average climbs without the team shipping anything faster. This is close to unavoidable once velocity becomes something people feel judged by, which is the strongest argument for never treating it as a performance number in the first place.

Outlier sprints are the mechanical one. A single sprint where half the team was out, or where one huge item finally landed after weeks of work, pulls a three-sprint average hard in one direction. The fix isn't a longer window by default (see the calibration point above) — it's noticing when a sprint was genuinely unusual and treating it as an exception rather than baking it silently into the trend.

Cross-team comparison is the most damaging one, because it looks so reasonable from a distance. Team A's velocity of 40 and Team B's velocity of 15 says nothing about which team is more productive, because 'what counts as a 3' was never calibrated between them — it's an internal, relative unit each team invented for its own forecasting, not a standardized measure of output. Ranking teams by velocity is comparing two rulers with different unit lengths and calling it a race.

Velocity vs throughput vs cycle time

Throughput — the raw count of items finished per period, with no estimation involved — sidesteps the point-inflation problem entirely, because there's no unit to inflate. It's the basis for forecasting delivery without estimating a thing, which uses historical throughput and Monte Carlo sampling instead of story points to answer 'when will this ship' with a confidence level. Cycle time — how long a single item takes from start to finish — answers a different question again: not 'how much do we finish per sprint' but 'how long does one thing take once we start it,' which is often the more actionable number when something feels slow. None of the three replaces the others; they measure related but genuinely different things about the same work.

Story points vs just counting issues

It's worth asking why a team estimates in points at all rather than just counting completed issues, which is what throughput does. Points exist to normalize for size — ten small bug fixes and ten sprawling features are both '10 issues,' but they're not the same amount of work, and points are the team's attempt to say so. That's a real benefit when issue sizes vary a lot. But it comes at the cost of an entire extra estimation process that itself takes time and is itself often wrong, and if a team keeps its issues reasonably similar in size to begin with, plain issue count can be nearly as predictive with none of the estimation overhead. Which one is worth it depends on how much your issues actually vary in size — the more uniform they are, the less points are buying you.

When to stop trusting your velocity number

Reset your expectations, not just your spreadsheet, whenever the team composition changes meaningfully, the sprint length changes, or the team redefines what a point means (even informally, which happens more often than anyone admits). A velocity average carried across one of those changes isn't wrong exactly — it's answering a question about a team that doesn't exist anymore. Try the calculator to see the trailing-average math on your own sprint history, and if the backlog feeding those sprints is cluttered with duplicates and stale asks that never should have been pointed in the first place, AI triage is where that gets cleaned up before it distorts the number.