NoEstimates Exploration

---

Origins

The #NoEstimates movement was articulated and amplified by Woody Zuill, Vasco Duarte¹, Neil Killick, and others in the early 2010s. The argument: most estimation work in software is wasted effort that produces fictional numbers with high cost and low value. If items are kept reasonably small and uniform, throughput — how many items the team completes per period — is a more honest basis for forecasting than estimation ever was.

The movement was deliberately provocative. The hashtag and the slogan "no estimates" overstated the position to force a debate the broader Agile community had been avoiding. The serious version of the position is more nuanced: estimate when estimation produces value, skip it when it doesn't, and forecast from data when you can.

The Core Argument

Conventional estimation has several costs:

• Estimation meetings consume team capacity (and senior developer attention).
• Estimates are routinely wrong for the work that matters most (complex, novel).
• Estimates become commitments stakeholders hold the team to.
• Padding compensates for systematic optimism but creates its own problems.
• Story points are abstract enough to be debated endlessly.

If the team can produce reliable forecasts without estimating, all of those costs disappear. The NoEstimates premise is that this is possible — provided the team is willing to keep work items reasonably small and to measure their actual completion rate.

How NoEstimates Works

1. Keep stories small

The single hardest discipline. Stories need to be roughly similar in size — not identical, but within an order of magnitude. Outliers get split before they enter the backlog. This requires real refinement skill.

2. Count completions

Per sprint or per week, count how many stories the team completes. Track over time. This number is the team's throughput.

3. Forecast from throughput

"We complete 7-12 stories per sprint, 90% of the time." Given a backlog of N stories, the team can forecast a release date range based on historical throughput. Monte Carlo simulation makes this rigorous; back-of-envelope arithmetic works for less formal contexts.

4. Adjust as evidence accumulates

Throughput shifts with team changes, technology shifts, and learning. Re-forecast as the team learns.

What NoEstimates Solves

• Wasted estimation time: hours of Planning Poker per sprint become zero.
• Story point arguments: no story points means no debates about whether something is a 5 or an 8.
• False precision: throughput-based forecasts come with explicit confidence ranges.
• Estimate-as-commitment dynamics: there's no per-item estimate to be held to.
• Focus on splitting: the team's discipline shifts from estimating to refinement. Often produces better-shaped backlog work as a side effect.

What NoEstimates Requires

• Strong refinement discipline: stories must be kept roughly uniform. Teams that can't do this can't make NoEstimates work.
• Historical data: the forecast comes from past throughput. New teams without history have nothing to forecast from.
• Stakeholder willingness to think in ranges: throughput-based forecasts are probabilistic. Stakeholders who insist on single-date commitments will be unhappy.
• Stable team and work mix: throughput shifts with team and work changes. Wildly variable contexts produce unreliable forecasts.

Monte Carlo Forecasting

The rigorous version of NoEstimates forecasting uses Monte Carlo simulation. Take the team's historical throughput distribution; simulate completing N stories thousands of times; produce a probability distribution of finish dates.

Output: "85% confidence by date X, 50% confidence by date Y, 15% confidence by date Z." Stakeholders get honest probabilistic forecasts instead of single-point estimates that pretend confidence the team doesn't have.

Tools like Actionable Agile (Daniel Vacanti²) automate the math. Or a spreadsheet can do it — the technique is approachable for teams that want to try it.

Where NoEstimates Doesn't Fit

• Highly variable story sizes: when items range from one-day fixes to month-long features, throughput is a meaningless aggregate.
• New teams or new domains: no historical data to forecast from.
• Fixed-scope, fixed-date contracts: throughput forecasts produce date ranges. Contracts that demand single dates and fixed scope require different planning.
• Multi-team coordination: aggregating throughput across teams with different definitions of "story" produces nonsense.
• Stakeholders who can't tolerate probabilistic answers: cultural fit matters.

The Middle Ground

Most teams that adopt NoEstimates ideas don't fully abandon estimation. The pragmatic pattern:

• Skip story-point estimation for most items.
• Maintain rough size triage — T-shirt or Roman — to flag outliers that need splitting.
• Forecast with throughput-based methods.
• Estimate explicitly when stakeholders need date commitments that historical data alone can't anchor.

The middle ground keeps the costs low and the forecasting honest without fighting the religious war.

Common Pitfalls

• NoEstimates without refinement discipline: skipping estimation but not investing in story splitting. Throughput becomes meaningless.
• Throughput as a target: when "complete more stories per sprint" becomes the goal, teams start gaming the metric by splitting items meaninglessly.
• Forecasting from too little data: a team with three sprints of history forecasts a six-month release. The data isn't sufficient.
• Religious adoption: insisting on NoEstimates even when stakeholders genuinely need date-based commitments. Pragmatism beats dogma.
• Throughput without context: presenting "9 stories per sprint" without distribution, variance, or confidence ranges. Single numbers about probabilistic processes mislead.

Coaching Tips

Invest in Refinement First

NoEstimates depends on uniform story sizes. Without strong story splitting, throughput is meaningless. Build the refinement muscle before abandoning estimates.

Communicate in Ranges

"85% confidence by X, 50% by Y" is honest. Single-date forecasts from throughput data hide the probabilistic nature of the math.

Watch for Throughput Gaming

If the team is splitting stories meaninglessly to boost the count, the metric has become the target. Re-anchor on the actual purpose.

Use Monte Carlo

Probabilistic forecasting from throughput history is more honest than single-point estimation. Tools exist; the math isn't hard.

Allow Pragmatic Hybrids

NoEstimates as religion produces fights; NoEstimates as one tool in the kit produces value. Don't insist on purity.

Read the Stakeholder Culture

If stakeholders genuinely need single-date commitments and won't tolerate ranges, NoEstimates won't work. Adapt or change stakeholders, not your math.

Summary

The NoEstimates conversation has produced more heat than light at times, but the underlying insight is sound: most software estimation work is high-cost theater that produces fictional precision, and teams that can replace it with throughput-based forecasting often produce more honest plans for less effort. The movement's deliberately provocative framing pushed back against an estimation culture that had grown defensive about its own value.

The honest middle position is the one most mature teams converge on: don't fight estimation when it produces value, don't waste time on it when it doesn't, and learn to forecast from history when the data is there. Story points are a tool, not a commandment; throughput is a tool, not a commandment; the team's job is to give stakeholders honest forecasts they can plan around using whatever combination of tools fits the situation.

Back to Agile Delivery