Story points were invented to make estimation less about hours. Somewhere along the way, teams flipped them into a precise forecast and a performance metric. They're neither, and the research on how badly software estimates hold up should settle the argument.
Key Takeaways
- Studies find most software projects overrun their effort estimates, commonly by 20–40% (research on story points and effort).
- Story points correlate weakly with actual hours (Ben Northrop), so velocity is a shaky forecasting tool.
- Points do work for relative sizing; the mistake is treating the velocity that falls out as a precise forecast (Plane).
- Measure delivered outcomes (DORA metrics), not estimated points.
The Core Problem
Story points estimate relative size, not time. The catch, as Ben Northrop lays out, is that the correlation between points and actual hours is weak, and the weaker it is, the more unreliable velocity gets as a forecast. "We did 57 points last sprint, so we'll do 57 again" quietly assumes a precision the numbers don't have.
The academic literature is not kind to software estimates in general. Studies of story points and development effort find the two correlate only loosely, and broader reviews of estimation research find most projects exceed their effort estimates, with overruns commonly in the 20 to 40% range (research on story points and development effort). Estimation is hard, humans are bad at it, and no amount of Fibonacci-number ritual fixes that.
Points do earn their keep in one place: relative sizing during planning. The mistake, as Plane's analysis points out, is treating the velocity that falls out of them as a precise forecast rather than a rough, shifting signal.
Where It Does Real Damage
Two failure modes are common. First, leaders forecast delivery dates from velocity and are shocked when they slip, because the points never mapped to time. Second, and worse, velocity becomes a target. The moment you manage to a points number, people inflate estimates to hit it, and the metric dies. It's Goodhart's law on a sprint board: when a measure becomes a target, it stops being a good measure.
| Velocity used as... | Result |
|---|---|
| A rough capacity feel | Fine |
| A precise date forecast | Misleading |
| A performance target | Gamed and useless |
A Concrete Version
A CTO tells the board "we do 60 points a sprint, the release is 300 points, so it ships in five sprints." Then reality: a couple of stories were secretly double their estimate, one sprint got eaten by an incident, and estimates crept up because the team learned that 60 was the expectation. Seven sprints later it ships. The 300-point plan was never a forecast; it was a wish with a number on it. Nobody lied. The tool just doesn't do what it was being asked to do.
The Honest Counterpoint
This isn't "estimation is useless, go estimate nothing." Rough sizing genuinely helps: it surfaces disagreement ("wait, why do you think that's a 2 and I think it's an 8?"), forces scope conversations, and gives a loose sense of capacity. Story points are a fine planning aid. The failure is precision-washing: dressing a rough guess up as a delivery date or a productivity score. Use points for the conversation, not the commitment.
What to Measure Instead
If you want to know how your engineering org is actually doing, measure what it ships and how reliably, not what it guessed. DORA metrics, deployment frequency, lead time, change failure rate, track real delivery and can't be gamed by inflating estimates. They have a second benefit: because they measure outcomes rather than desk time or ceremony, they work identically for in-office, remote, and nearshore teams. See available engineers.
Frequently Asked Questions
Are story points useless?
No. They're fine for rough relative sizing in planning conversations. The problem is treating velocity as a precise forecast or a performance target, which the weak points-to-time link can't support.
How inaccurate are software estimates, really?
Estimation research finds most projects overrun their effort estimates, commonly by 20 to 40%, and story points correlate only loosely with actual hours. Software estimation is genuinely hard.
Why is velocity a bad forecasting tool?
Because story points correlate weakly with actual hours. Forecasting a date from velocity assumes a precision the numbers don't have, and the moment velocity becomes a target, people inflate estimates and it stops meaning anything.
What should I measure instead?
Delivered outcomes: DORA metrics like deployment frequency and lead time. They track real delivery, resist gaming, and work for distributed teams.
The Bottom Line
Story points are a planning aid, not a forecast, and velocity is not a performance metric. The research is clear that software estimates overrun routinely, so stop dressing them up as dates or scores. Measure what actually ships with DORA-style delivery metrics, and you manage reality instead of a number your team can quietly inflate.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
