Velocity

Velocity is a forecast input, not a KPI. The moment you measure teams on it, it inflates.

Velocity is the average number of story points a team completes per sprint over the last few sprints. That's the whole definition. It exists for one job: projecting how many sprints a backlog will take to ship, given the team's actual rate of delivery. Sum the points remaining, divide by velocity, you have a forecast. That is the only thing it does honestly.

Every other use breaks it. "Why was velocity lower this sprint?" turns each retrospective into a defense of the number. "Team A has a higher velocity than Team B" treats two teams' independent calibrations as comparable when they aren't. "We need to increase velocity by 20% this quarter" tells the team to make the number go up, and the team will — by sizing the same work bigger, not by doing more of it. Goodhart's law, running on a two-week cycle.

How to calculate it

Take the points completed in each of the last three to five sprints. Average them. That's your velocity. Don't adjust for "exceptional" sprints — the exceptional sprints are part of the signal you're trying to smooth out. Don't include carried-over work twice. Don't count partially-completed stories at all; they get counted in the sprint they actually finish in. The simpler the calculation, the harder it is to game.

Velocity stabilizes after the team has been running together for three or four sprints. New team, new reference story, a major personnel change — all reasons to throw out the prior number and rebuild from scratch. The number isn't a property of the technique; it's a property of this team in this period of time. A team that lost two members yesterday has yesterday's velocity for a different team.

What goes wrong

The single most common failure mode: a manager reads a velocity number and reads it as "how productive is this team?" The number then gets quoted in status meetings, then compared across teams, then targeted. Within two sprints, the team has rebased its sizing to make the number go up — every story now sizes 30% bigger than it used to — and the velocity number has stopped meaning what it used to mean. The forecast it was supposed to produce is now wrong. See velocity as a productivity metric for the longer version of this failure mode.

The second: comparing teams. Two teams sizing the same backlog will produce different velocity numbers because they're using different reference stories — that's the whole point of relative estimation. Comparing the two numbers is like comparing two thermometers with different zero points. The numbers don't mean the same thing, and treating them as if they did corrupts both teams' calibration.

What it's actually for

Forecasting. The PM asks "when will the backlog be done?" — sum the points, divide by velocity, get a range. The team plans this sprint and wants to know if they're over-committing — points proposed for this sprint should be within shouting distance of the recent average. That's it. Two uses. If someone is using the number for a third thing, they're using it wrong, and the question to ask is "what are you actually trying to measure?" rather than "how do we increase velocity?"

Use velocity to forecast. Never to compare teams. Never as a target.

Adjacent: how many story points per sprint for the sizing-the-sprint question; story points vs hours for the related conversion failure mode; common mistakes covers velocity-as-KPI as a recurring pattern.