The no estimates vs story points argument is back on LinkedIn — again. A long-running thread from Allen Holub arguing against estimation has pulled in over 500 comments, split between practitioners who say story points are the backbone of team planning and those who say they’re expensive theater. After a decade of this debate, the striking thing isn’t who’s winning. It’s that both camps keep arguing about the wrong layer of the problem.

What each side actually claims

The story-points camp says relative sizing forces the conversation that surfaces hidden complexity: when one engineer says 3 and another says 8, the gap is the value. Points feed velocity, velocity feeds forecasts, and forecasts are what stakeholders need to plan around.

The no-estimates camp counters that most estimation sessions produce numbers nobody trusts, that points get weaponized into productivity scores, and that counting finished items — throughput — forecasts just as well without the ceremony. Slice stories small, count what you finish, project forward.

Here’s what the thread misses: the no-estimates position is still an estimate. “We finished eight items last sprint, so expect around eight this sprint” is a forecast built on historical data — exactly what velocity is, minus the sizing step. The real question was never whether to estimate. It’s which input to your forecast is cheapest to produce and hardest to game.

The variable both camps ignore: capacity

Whether you size in points, count throughput, or refuse to write a number down at all, every sprint forecast silently assumes the team that delivered last sprint is the team delivering this one. That assumption breaks constantly. Someone is on leave. Someone is pulled 40% onto a production incident. A holiday lands mid-sprint. The estimation method didn’t fail — the capacity behind it changed, and nobody adjusted.

This is why teams switch from points to no-estimates (or back) and see no improvement in predictability. They swapped the sizing method but kept planning against an idealized team that doesn’t exist this sprint. Our breakdown of story points vs hours makes the same argument from a different angle: the unit matters less than whether it’s anchored to real availability.

A practical settlement

Teams that are calm about this debate tend to converge on the same hybrid, whatever they call it:

• Keep sizing conversations where they surface risk — but timebox them. The discussion is the product; the number is a by-product.
• Forecast from throughput history, not from summed guesses. Past delivery is evidence; a fresh estimate is opinion.
• Reconcile every commitment against this sprint’s actual person-days — leave, allocations, meetings — before anyone promises anything.

That last step is the one almost no tooling supports well, and it’s where the argument stops being philosophical. A forecast method is only as good as the capacity number underneath it.

Doing this in Jira

Sprint Planning, Capacity & Resource Planning for Jira handles exactly that reconciliation: it tracks each member’s real availability — time off, partial allocations, shared duties — and holds the sprint commitment against it, whichever estimation unit your team uses. Points-based teams see when the point load exceeds the people; no-estimates teams see when this sprint’s capacity no longer resembles the history their throughput forecast assumes.

Either way, the debate gets smaller. Sizing method becomes a team preference. Capacity becomes the shared fact.

Where to go deeper

If your team is re-litigating no estimates vs story points this quarter, start from the planning workflow rather than the philosophy: our complete guide to sprint planning covers goal-setting, capacity, and commitment end to end, and common sprint planning mistakes catalogs the failure modes that show up regardless of which side of the estimation debate you’re on. Pick the method your team argues about least — then spend the reclaimed energy on the capacity number both methods depend on.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio