What is Sprint Velocity?

Stakeholders and customers get a defensible answer to when something will be delivered, based on evidence rather than optimism.

The metric, defined

Sprint velocity is the key planning metric in Scrum. It is the analysis of past workloads to work out how much can realistically be done in future sprints — calculated at the end of each sprint by adding up the points for all completed user stories.

Two words in that definition do the heavy lifting. Completed: partially finished work scores nothing. And past: velocity is an observation of what happened, not a target set in advance.

What it is genuinely useful for

With a few sprints of history, a team can plan with some confidence: how much can be committed to, how long a body of work is likely to take, and therefore what resource and time a project actually needs.

The value most often felt outside the team is in expectation-setting. Stakeholders and customers get a defensible answer to when something will be delivered, based on evidence rather than optimism.

How to estimate it

Take the completed story points from each of the last several sprints and average them. Three sprints is the minimum for anything meaningful; five or six gives a range you can plan against.

Plan against the range, not the average. A team averaging 30 points with a spread of 22 to 38 should not be committing to 30 every sprint — over half the time, it will miss.

Stabilising it

An erratic velocity is more of a problem than a low one, because it makes planning impossible. The usual causes are worth checking in order:

• Changing team composition — velocity belongs to a team, not to individuals, and it resets when the team changes
• Inconsistent estimation, where a five means different things in different sprints
• Unplanned work arriving mid-sprint
• A weak definition of done, which pushes work into the following sprint
• Carry-over, which flatters one sprint and penalises the next

Protecting the sprint once it has started

Two disciplines matter once planning is done and the sprint is under way. First, don't change the backlog mid-sprint — adding or removing stories once work has begun is the equivalent of redesigning a building while it's half built, and it's the single fastest way to make velocity meaningless again. Second, surface blockers immediately rather than absorbing them quietly; an impediment raised on day one is a small adjustment, the same impediment discovered at the retrospective is a missed sprint.

The warning

Velocity becomes actively harmful the moment it is used to compare teams or as a performance target. Story points are relative to a team's own scale, so comparisons are meaningless — and a team measured on velocity will inflate its estimates, which produces a rising number and no additional software.

Use it to plan. Do not use it to judge.