#NoEstimates: What It Actually Argues, and When It Works

Few agile topics generate more heat and less clarity. Most arguments about #NoEstimates are between someone defending a nuanced position and someone attacking a slogan.

Worth separating the two, because the underlying idea is useful even if you keep estimating.

The actual claim

The strong version of the argument isn't "never predict anything". It's roughly:

Estimation is a cost. On many teams it buys less forecasting accuracy than simply counting how many items you finish per week. Where that's true, the estimation effort is waste.

That's a testable claim, not an ideology. And on a fair number of teams, it's true.

Why counting often works as well as estimating

If your stories are consistently sliced to a similar size, the number of stories you finish per week is a stable number, and stable numbers forecast well. Multiply items-remaining by your historical cycle time and you get a date, without anyone having voted on anything.

This is the same statistical effect that makes velocity work, minus the step where you assign points. The points themselves aren't doing the forecasting; the consistency is.

The conditions it depends on

Counting instead of estimating works when:

• Stories are sliced small and evenly. This is the load-bearing condition. If your items range from an afternoon to a month, counts are meaningless.
• Work arrives continuously. Flow-based teams get more from cycle-time data than sprint-based teams do.
• You have history. You need dozens of completed items before the distribution means anything.
• Nobody needs a number before the work exists. If budgets or contracts require a forecast for unstarted work, you need some kind of estimate.

Miss those conditions and dropping estimation removes your only forecasting tool.

What estimation buys that counting doesn't

Even where counting forecasts well, the estimation conversation does things a count can't:

• It surfaces disagreement about scope before the work starts, which is most of the value of planning poker in the first place.
• It exposes hidden assumptions: the spread of votes is a signal, and a count has no spread.
• It gives you a shared vocabulary for "bigger than we thought".

Teams that drop estimation and keep a short scope conversation usually do fine. Teams that drop the conversation along with the numbers tend to rediscover why it existed.

A reasonable middle

Try this before adopting a position: for two months, record both your points and your item counts. Then check which one would have forecast your actual delivery better.

If counts win, you've learned that your estimation effort isn't buying accuracy, so spend the session on splitting stories and clarifying scope instead, and keep the discussion without the voting. If points win, you have evidence to end the argument. Either way you replaced a debate with a measurement, which is more than most of the internet has managed.

The useful question isn't whether to estimate. It's what your estimates are buying you, and whether something cheaper would buy the same thing.