Story points vs #NoEstimates: our verdict

Neither camp wins outright. Estimate to build shared understanding and detect disagreement; don't estimate to predict a date — forecast from throughput. We steelman story points, #NoEstimates and the inventor who disowned points, then rule.

Neither camp wins outright. Estimate to build shared understanding and to detect disagreement; don’t estimate to predict a date — forecast from throughput instead. The point number is nearly worthless. The conversation that produced it is the whole asset.

The argument gets framed as a binary — points or no points — and it isn’t one. Both camps are right about something, and both have a heavyweight authority behind them. The useful position is the one that takes each side’s strongest claim and keeps only the parts that survive contact with a real sprint.

The case for story points

Mike Cohn’s argument, the definitive pro-points position, was never really about the number. It’s that the act of estimating relatively forces a team to discuss complexity, surface hidden assumptions and agree on what a story actually involves before anyone writes code. Points also sidestep a specific pathology: estimate in days and every number gets haggled; estimate in an abstract unit and the haggling has nothing to grab. The catch is that everyone hears the wink — “we’re not estimating time, just complexity, so we can plan the sprint, which is two weeks” — and the abstraction only protects the team for as long as no one converts it straight back to a date.

Steve McConnell supplies the rigorous counterweight to the anti-estimation crowd. His claim is that the root cause of bad estimates is usually a lack of estimation skill, not estimating itself — and that serious estimators separate three things the debate keeps mashing together: the estimate (what’s likely), the target (what the business wants) and the commitment (what the team promises). Conflate them and of course estimation looks broken. Keep them distinct and it does real work.

The case for #NoEstimates

Now the other side, at full strength. Allen Holub’s objection is that estimates are always inaccurate, usually wildly so, and that story points were meant to obfuscate duration so managers would stop pressuring on time — yet teams reverse-engineer them straight back to hours, recreating the exact dysfunction points were invented to prevent. The Fibonacci scale doesn’t save you if everyone privately holds a points-to-hours conversion table.

The sharpest data-flavored claim comes from Vasco Duarte: on real projects, simply counting stories forecasts about as well as summing their story points. If that holds for your work, the points are pure ceremony — you did arithmetic to arrive at the same answer the count already gave you. Measure throughput and cycle time instead; a growing queue is a leading indicator you can see coming, where velocity is a lagging one.

And then the sharpest card in the whole debate. Ron Jeffries, who is widely credited with inventing story points, walked them back in 2019: “I may have invented story points, and if I did, I’m sorry now.” His problem is specifically with using them to predict when work will finish and to compare teams. His alternative isn’t “stop planning” — it’s slicing stories thin enough to need a single acceptance test, ideally under a day each, so there’s barely anything left to estimate.

Where we would change our mind

We would go full #NoEstimates for a team whose work is already sliced small and uniform. Once every story is roughly a day, counting stories forecasts as well as summing points, and the estimation meeting is overhead you can delete — McConnell concedes as much, naming fast-cycle work where the mission is simply “do the next most useful thing” as a context where estimates add little.

We would relax our guard against points in the opposite case: an org where estimates genuinely never harden into commitments and nobody compares teams. There, the danger the anti-estimation camp warns about doesn’t exist, and points are just a harmless conversation prompt. The trouble is that this org is rare. The weaponisation is the default, which is why our verdict leans the way it does.

The practical take

one story 3 13 one dev another dev the gap is the point talk it out — don’t average A 3 beside a 13 means you’re picturing different work.
The output of planning poker isn’t the number, it’s the gap. A 3 beside a 13 means two people picture different work — close it with conversation, don’t split the difference.
  • Treat planning poker as a disagreement detector, not a prediction machine. A 2 and a 13 on the same story is the signal — it means the team does not share an understanding of the work. Talk until the spread collapses; the agreement is the output, not the final number.
  • Forecast from throughput and cycle time, not from summed points. Velocity is a planning input for the team, never a promise to the outside.
  • Separate estimating from committing, as Cohn says. An estimate is a guess; the moment it becomes a promise, someone has changed its meaning without telling the team.
  • If you keep points, keep them relative. The instant they map to hours you’re estimating duration in disguise — with all the pressure of hour-estimates plus a layer of obfuscation.
  • Slice the story rather than sizing it. Jeffries is right that most of the value the debate fights over disappears when stories are small enough that the estimate barely matters.

The number is worthless; the conversation that made it is the point. That single line resolves most of the fight — and it keeps a planning poker session genuinely useful without pretending it can see the future.

Frequently asked questions

Should we use story points or #NoEstimates?

Use whichever makes the estimating conversation happen, and stop treating the number as a prediction. Story points are useful as a disagreement detector — a wide spread on one story means the team does not share an understanding of it. #NoEstimates is the right call when your stories are already sliced small and uniform, because then counting them forecasts as well as summing points. Either way, forecast delivery from throughput, and separate estimating from committing.

Did the inventor of story points really disown them?

Ron Jeffries, who is widely credited with coining story points, wrote in 2019: “I may have invented story points, and if I did, I’m sorry now.” His objection is to using them to predict completion dates and to compare or grade teams. His recommended alternative is not “no planning” — it is slicing stories small enough to need a single acceptance test.

How do you forecast a release without estimating every story?

Measure throughput — the number of stories the team actually completes per week — and project the remaining backlog against that rate. Vasco Duarte’s finding is that counting stories forecasts about as well as summing story points, so once stories are sliced to a similar size, the points add little the count does not already give you.