Forecasts, not promises

Somewhere in most organisations that “do Scrum”, a chart shows velocity going up and to the right, and someone is pleased about it. This lesson is about what that chart can and can’t tell you, and about the number that answers the question the chart is being asked.

What the Scrum Guide says, and doesn’t

The 2020 Scrum Guide never uses the words “story point”, “velocity” or “estimate”. It mentions sizing once: “The Developers who will be doing the work are responsible for the sizing.” On forecasting it says: “Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism.” What a team commits to in a Sprint is the Sprint Goal, and “Scope may be clarified and renegotiated with the Product Owner as more is learned.”

So a velocity target is not part of Scrum. It’s something organisations add, and it changes what the number means.

The person who may have invented story points

Ron Jeffries, one of the authors of the Agile Manifesto, wrote in 2019: “I may have invented story points, and if I did, I’m sorry now” - and, closing the same article, “I’m probably a little sorry now, but not very sorry.” In his account, the team first estimated in ideal days, then multiplied by a load factor that “tended to be about three”, and points were a way to stop arguing about why an ideal day took three real ones. His warning about how they are used now is direct: “I think comparing teams on quality of estimates or velocity is harmful.” And: “Increasing pressure to do more almost inevitably has a bad result: the team tries to go faster, and wind up skimping on code quality and on tests.”

The general idea is usually called Goodhart’s law, after the economist Charles Goodhart’s observation about monetary statistics in the mid-1970s. The popular one-line version - that a measure turned into a target stops being a good measure - is a later generalisation by other writers, not Goodhart’s own words. We haven’t been able to read the originals, so we don’t quote any of them here.

Try it

The same Flow Lab, with sprints. A velocity target makes each sprint’s estimates a little bigger. Nobody lies; the same work just gets sized up under pressure. The rate of inflation is invented. No study we could find measures how fast points inflate under a target, and figures you may see quoted, like “40% inflation”, have no traceable source either.

Forecasting without points

If points can drift, how does a team answer “when will it be done”? The Kanban Guide’s approach uses what already happened: throughput as an exact count, and cycle time as a distribution. “85% of items finish within 10 days” is a forecast built from the team’s own history, which a target can’t inflate without the team actually finishing faster. The trade-off is honesty about uncertainty: you get a range and a confidence level, never a single date.