Estimate relative effort, not hours. Story points plus velocity answer “how much can we commit to?” — but the moment they become a productivity target, they're gamed into uselessness.
▸ Try the interactive toolEvery Agile team faces the same hard question: how much can we commit to in the next sprint? Answer too high and you overpromise, miss, and erode trust; too low and you sandbag and waste capacity. Story points (relative effort estimates), velocity (points delivered per sprint), and planning poker (collaborative estimation) exist to answer that question without pretending to a false precision.
The crucial idea is that story points estimate relative effort and complexity, not hours. A 5-point story is roughly five times a 1-point story — the team isn't claiming it takes five hours or five days. This relative approach is more honest than time estimates because humans are bad at absolute time prediction but decent at relative comparison. Velocity then emerges empirically: the team's average points-per-sprint becomes a forecasting tool — not a productivity score.
Story points — relative effort/complexity (not hours)
Velocity — points the team delivers per sprint, averaged over time
Planning poker — simultaneous, collaborative estimation that surfaces hidden assumptions
The single fastest way to ruin story points is to treat velocity as a performance metric — the moment it's a target, teams inflate estimates and the number stops meaning anything.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Velocity as a target | Treated as productivity, teams inflate points; the number becomes meaningless. | Velocity stays a forecasting tool, kept out of performance reviews. |
| Points as hours | Converting points to hours reintroduces the false precision they avoid. | Relative estimation plays to what humans are actually good at. |
| Comparing teams' velocity | Team A's 40 vs Team B's 25 is meaningless — different scales. | Velocity is only valid within one team over time, never across teams. |
| Solo estimation | One person's estimate misses others' knowledge of hidden complexity. | Planning poker surfaces disagreement and hidden assumptions. |
Size stories against each other using a points scale (often a Fibonacci-like sequence). Ask ‘how big relative to that one?’, never ‘how many hours?’
Have the team estimate simultaneously and privately, then reveal. Big disagreements are the signal — they reveal hidden complexity or differing assumptions worth discussing before committing.
Track points actually completed per sprint and average over several sprints. Don't set a target velocity — measure the real one. A few sprints in, it becomes a useful forecast.
Use velocity to answer ‘how much can we take on?’ and ‘roughly when will this be done?’ Never use it to rank people or teams — that's what corrupts it.
The instant leadership treats velocity as productivity, estimates inflate to hit it. Actively keep velocity out of performance contexts to keep it honest.
A leadership team started celebrating rising velocity and asking why one team's number was lower than another's. Predictably, velocity climbed — not because more got done, but because estimates quietly inflated. A 3-point story became a 5, then an 8. The number went up; the output didn't.
Velocity had been turned into a target, and per Goodhart's law it stopped being a useful measure the moment it became one. The fix was to pull velocity entirely out of performance discussions and restore it to what it's for: the team's own private forecasting tool for how much to commit to next sprint. Once it wasn't being judged, the estimates re-stabilised and the number meant something again.
The deliverable is an empirical velocity (averaged over several sprints) used purely to forecast commitment — never to compare teams or judge people.
| Use velocity to… | Never use velocity to… |
|---|---|
| Forecast next sprint's commitment | Rank or judge individuals |
| Roughly project a roadmap | Compare across different teams |
| Spot your own trend over time | Set as a target to hit |
| Plan capacity honestly | Convert points back into hours |
Story points work because they swap a thing humans are bad at (absolute time estimation) for one they're decent at (relative comparison). Velocity works as a forecast — and breaks instantly the moment it becomes a target.
This is Goodhart's law in miniature: when a measure becomes a target, it ceases to be a good measure. Velocity is genuinely useful for the team's own planning — it answers “how much should we commit to?” with empirical honesty. But the instant it travels upward into performance reviews or cross-team comparisons, the incentive flips: inflating estimates raises velocity without raising output, and the metric self-destructs. The PM's real job here is partly protective — keeping velocity in the team's hands as a forecasting aid and out of the contexts that would corrupt it. And remembering that points are relative and team-specific means a team's velocity is meaningful only against its own history, never against another team's different scale.
The cardinal error. It triggers estimate inflation and destroys the metric. Keep it for forecasting.
Points are relative to each team. Cross-team comparison is meaningless.
This reintroduces the false precision points exist to avoid. Keep estimates relative.
Planning poker's disagreements reveal hidden complexity. Estimate as a team.
Velocity is one input to a sustainable commitment; capacity (Tool 08) is the other.
Story points and velocity are the raw material of the sprint-planning event (Tool 06).
Shielding velocity from becoming a target is part of the PM's in-sprint role (Tool 16).
Where Scrum uses velocity, Kanban (Tool 09) measures flow — cycle time and throughput.
Imagine leadership starts publishing each team's velocity on a dashboard and praising the highest. Predict what happens to the estimates over the next few sprints.
Then describe how you'd keep velocity useful: what would you change about who sees it and how it's used?
If you predicted estimate inflation, you've understood why velocity must stay a forecasting tool — the moment it's a target, it measures gaming rather than work.