Velocity in Scrum

Velocity is the total number of story points a team completes in a single sprint. If a team finishes stories worth 8, 5, 5, 3 and 2 points, its velocity for that sprint is 23. Two words in that definition carry most of the weight. Completes means the work met the team’s Definition of Done — not that it was nearly finished or was merged but untested. Partial credit destroys the metric, because a sprint that ends with six stories at ninety percent will report a healthy velocity while delivering nothing. Team means this specific group of people with their current tooling and codebase. Velocity is not a property of the work; it is a property of a team doing that work, which is why the number is meaningless outside its own context.

Sum the points of every story that met the Definition of Done inside the sprint boundary. That is the whole calculation — the subtleties are all in what you exclude. • Do not count partially finished stories. Carry them at full value into the sprint where they actually complete. • Do not re-estimate a story mid-sprint because it turned out bigger. The original estimate is what the forecast was built on, and changing it retroactively hides the error you want to learn from. • Do not count unplanned work unless you estimated it. If interruptions are constant, either estimate them or explicitly reserve capacity for them — do not pretend they were free. • Do not add points for effort spent on abandoned work. It consumed capacity, but it delivered nothing, and velocity is a delivery measure. For forecasting, a single sprint is close to useless. Use a rolling average of the last three to five sprints, and keep the range rather than the mean: a team that has delivered 28, 35, 31, 40 and 33 points has a velocity of roughly 30–40, and that spread is the honest part of the estimate.

A new team has no velocity, and the first few sprints will produce numbers that jump around considerably. This is normal. The team is simultaneously calibrating its scale, learning the codebase, and discovering how much interruption a typical sprint carries. In practice expect three to five sprints before the range settles, and longer if the team composition keeps changing. Until then, plan conservatively and avoid quoting the number to anyone who might treat it as a commitment. Velocity also legitimately resets. A significant change in team membership, a move to an unfamiliar part of the system, or a major shift in tooling will all invalidate the historical average. When that happens, say so rather than quietly carrying forward a forecast built on a team that no longer exists.

The main legitimate use of velocity is answering “roughly when will this body of work be done?” If a release contains 180 points of estimated work and the team’s velocity range is 30–40, the arithmetic gives five to six sprints. Quote both ends. A few things make that forecast more honest. Re-run it every sprint with the updated backlog and the updated average, rather than treating the first projection as fixed. Include the unestimated remainder — a release is rarely just the stories that have been refined, and forecasting only the known work systematically under-predicts. And expect scope to grow: most bodies of work expand by some predictable factor as they are understood, and a team that tracks its own rate of scope growth can build it in. Velocity forecasting is not the only option. Counting completed stories per sprint — throughput — often forecasts about as well with no estimation at all, provided stories are broadly similar in size. If your team’s stories vary wildly, points will do better; if they are consistently small, throughput is cheaper and just as good.

The moment velocity is used to judge a team, it stops measuring anything. The failure mode is not that people cheat deliberately — it is that estimates drift upward under pressure without anyone deciding to inflate them. A story that felt like a 3 last quarter becomes a 5, velocity rises, the chart looks excellent, and precisely the same amount of software ships. This is why two rules are worth holding firmly. Never compare velocity between teams: a team averaging 50 is not outperforming one averaging 30, because the units are not the same units. And never set velocity as a target. Goodhart’s law applies with unusual force here, because the team both produces the measurement and controls its definition. If a team’s velocity is genuinely too low for what the business needs, velocity will not tell you why. The answer is in the things velocity aggregates away: how much time went to unplanned work, how long stories waited in review, how often work came back after being called done.

A few common patterns and what usually sits behind them: • Velocity rising steadily over many months — almost always estimate inflation rather than improvement. Re-anchor against reference stories and see whether a "3" still means what it did. • Velocity swinging violently sprint to sprint — usually stories too large relative to the sprint, so one carry-over moves the total dramatically. Split smaller. • Velocity suspiciously constant — often a team that has learned what number is expected and plans to hit it. Healthy velocity has noise in it. • Velocity high but stakeholders unhappy — the team is completing points rather than outcomes. Check what proportion of delivered points served the actual goal. • Velocity collapsing after a team change — expected, and not a performance problem. Rebuild the average rather than explaining the dip. In every case the number is a prompt to look at something else. Velocity is a decent forecasting input and a poor diagnostic, and treating it as the latter is the source of most of the harm done in its name.