Velocity, Used Honestly: A Plain Guide for Scrum Teams
Velocity is one of the most useful and most misused numbers in Scrum. Used honestly, it helps a team forecast how much it can realistically take on. Used as a performance target, it quietly corrupts everything around it. The difference comes down to understanding what velocity is — and, just as important, what it is not. It's worth saying up front that velocity isn't part of the Scrum Guide at all; it's a common complementary practice, which is exactly why teams need to be clear-headed about it.
In plain terms, velocity is the amount of work a Scrum Team completes in a Sprint, usually measured in the story points (or item counts) of the Product Backlog items that met the Definition of Done. Add up the points of everything truly finished this Sprint, and that's your velocity. Average it over the last several Sprints and you have a rough planning range for the next one.
What velocity is good for
Velocity earns its keep as a forecasting tool the team uses on itself. During Sprint Planning, knowing you have averaged, say, 30 to 38 points over recent Sprints keeps you from pulling in 60 points of work and missing badly. Over time it can help the Product Owner give stakeholders an honest, range-based forecast of when a set of backlog items might be done — useful in early 2021, when remote teams and shaky supply timelines made over-promising especially painful.
A sanity check during Sprint Planning, so the team commits to a realistic amount
A rough release forecast, expressed as a range rather than a false-precision date
An early signal worth a conversation when it swings sharply up or down
A figure that belongs to the team, for the team's own planning
How it gets abused
Velocity goes wrong the moment it becomes a goal that someone outside the team measures people against. Goodhart's law applies cleanly here: when a measure becomes a target, it stops being a good measure.
Comparing teams by velocity. Story points are a local currency. One team's 5 is another team's 13. Ranking teams by velocity compares numbers that were never on the same scale.
Setting velocity as a target. Tell a team to raise velocity and they will — by inflating estimates. The number climbs while the actual output stays flat, and now your planning data is fiction.
Treating it as productivity. Velocity counts points delivered, not value delivered. A team can post a high velocity shipping things nobody needed. The point of Scrum is outcomes, not point totals.
Punishing a dip. Velocity falls during holidays, onboarding, or hard technical work. Reacting to every wobble teaches the team to game the number instead of reporting it honestly.
The honest test is simple: velocity should help the team make better commitments, never be used to judge the team from outside. Let estimates stay consistent, watch the trend rather than the single Sprint, and remember the real measures of success are working product and value delivered — exactly the things velocity quietly stops describing the moment you turn it into a target.
If your teams are wrestling with metrics that drive the wrong behaviour, XNM's program & project delivery advisory helps you put forecasting and delivery measures to work without distorting the teams they're meant to serve.