Velocity: What It Is, What It Isn't, and How to Use It

If you have spent time on an agile team, you have almost certainly heard velocity cited in a meeting. Sometimes it is used well — as a quiet input to planning conversations. More often it surfaces in ways that cause harm: as a performance target, a cross-team benchmark, or a number that must keep going up. Understanding what velocity actually measures, and what it does not, is foundational to using it responsibly.

What Velocity Is

Velocity is the sum of story points completed by a Scrum team in a single Sprint. If a team completes items estimated at 8, 5, 3, and 5 points in a Sprint, their velocity for that Sprint is 21. Over several Sprints, a pattern emerges: the team's average velocity provides a basis for estimating how much work they can take on in a future Sprint.

That is the full definition. Velocity is a measure of throughput — specifically, of how much estimated work a particular team completes in a fixed time-box. It is about this team, with this definition of story points, working on this codebase or problem domain, in this organisational context. None of those qualifiers transfer to another team.

The legitimate uses of velocity follow directly from this definition. First, Sprint planning: if the team's rolling average velocity is 40 points, selecting approximately 40 points of work for the next Sprint is a reasonable starting estimate — subject to capacity adjustments for holidays, leave, or known interruptions. Second, release forecasting: if you have a backlog of 200 story points and an average velocity of 40, you can project roughly five Sprints to completion. Both uses treat velocity as a probabilistic input, not a guarantee.

What Velocity Is Not

Velocity is not a measure of productivity. It says nothing about the quality of what was built, the business value delivered, or whether the team is working on the right things. A team that inflates its estimates — consciously or unconsciously, under pressure or through grade creep — will show a rising velocity while delivering no more real output.

Velocity is not a performance target. When it becomes one, predictable things happen. Teams pad estimates to ensure they hit their number. Work that spills over gets quietly rolled forward and re-estimated. Items are declared done before they genuinely meet the Definition of Done. The metric rises; the actual rate of value delivery does not.

Velocity is not comparable across teams. Different teams estimate differently. A five-point story for one team represents a categorically different unit of effort than a five-point story for another. Comparing velocities across teams — or aggregating them into a programme-level velocity — produces a number that is arithmetically possible and practically meaningless.

Using Velocity Responsibly

The first principle of responsible velocity use is to work from a rolling average, not a single Sprint's number. Three to five Sprints of data begins to be meaningful; one Sprint is noise. A rolling average also shows you the trend: a stable team should show a relatively stable velocity over time, with natural variation. A steadily rising velocity in the absence of deliberate improvement work should prompt a conversation about estimation drift, not celebration.

Use velocity to generate planning ranges, not point estimates. Rather than saying "we will complete exactly 200 points in five Sprints," say "based on our recent average and the natural variation we have seen, we expect to complete this scope in four to seven Sprints, with the midpoint around five." This is more honest, and it is more useful — it prompts the right conversation about risk and contingency.

Know when velocity-based forecasting breaks down. It assumes a stable team, a stable way of estimating, and a backlog with reasonable consistency in how stories are sized. When any of those change — a team member joins or leaves, the team adopts a new technology, the backlog shifts from small enhancements to large architectural work — velocity becomes unreliable as a forecasting tool until a new baseline is established.

• Never use velocity as a performance target or present it to stakeholders as a productivity measure.

• Never compare velocity across teams or aggregate it at the programme level.

• Always use a rolling average (3 to 5 Sprints minimum) rather than a single-Sprint number.

• Express forecasts as ranges, not point estimates.

• Reset your velocity baseline when team composition or estimation approach changes significantly.

Used well, velocity is a modest but genuinely useful planning aid. Used poorly, it becomes a source of hidden pressure that undermines the psychological safety that high-performing agile teams depend on. The discipline is knowing the difference.

XNM Consulting supports agile transformations and Scrum implementations across public-sector and complex project environments. Learn more on our Program and Project Delivery page.