The Cone of Uncertainty

---

Origins

The Cone of Uncertainty was developed by Barry Boehm and elaborated by Steve McConnell in Software Estimation: Demystifying the Black Art (2006).¹ The concept describes how the range of possible outcomes narrows over a project's life: at the start, estimates can be off by 4× in either direction (a 16:1 range); by mid-development, perhaps 1.5×; near completion, well under 10%.

Boehm's original data came from waterfall projects, but the underlying principle applies to any system where uncertainty is highest at the start and reduces as work proceeds.

The Shape

Plotting estimate accuracy over project time produces a cone shape: wide at the start, narrowing toward completion. At the earliest concept phase, a project estimated at "6 months" might actually take anywhere from 1.5 months to 24 months — a 16x range. By the time requirements are well-understood, perhaps 4–9 months. By integration, maybe 5.5–6.5 months. At the end, the actual time is known.

Why The Cone Matters

The cone is a structured way to communicate the truth most stakeholders resist: early estimates are unreliable on principle, not because the team is bad at estimating. The unreliability is built into the situation. Knowing nothing about a project at start, no team's estimate could be more accurate.

Three implications follow:

• Don't commit to early estimates. Use them for go/no-go decisions and rough budgeting, not for promises.
• Re-estimate periodically. The cone narrows over time. Updated estimates have legitimately less uncertainty.
• Communicate uncertainty in ranges. "6–24 months" is more honest than "12 months" at concept stage.

The Cone in Agile Contexts

Some agile commentators argue the cone is too pessimistic for agile teams. In Boehm's waterfall model, the cone narrows because requirements are clarified up front; agile teams discover and adapt continuously, which can flatten the cone over time.

The honest middle: agile teams still face the cone, but they manage it differently:

• They explicitly accept the breadth at the start (no over-commitment to early estimates).
• They use short iterations to reduce uncertainty incrementally rather than in batched chunks.
• They re-forecast continuously (Monte Carlo from updated throughput data).
• They commit to scope flexibility, not to specific dates with specific scope.

What McConnell Actually Found

McConnell's later work added an important caveat: the cone doesn't narrow on its own. It narrows only if the team actively reduces uncertainty — through requirements clarification, prototyping, refining stories, learning. A team that does no uncertainty-reduction work will have just as much uncertainty at month six as at month one.²

This is the underlying message of agile practice: continuous learning is what causes the cone to narrow. Skip the learning, and the cone stays wide.

Common Misuses

• "The cone will narrow naturally." No. It narrows when the team actively learns. Without learning, uncertainty persists.
• "We can give you a precise estimate at concept stage." No team can. Anyone claiming otherwise is sandbagging or hopeful.
• "Agile eliminates the cone." No. Agile changes how it's managed but doesn't eliminate it.
• "Early estimates are useless." Also no. They're rough but useful for go/no-go decisions and rough budgeting.

How to Use the Cone in Stakeholder Communication

The cone is most useful as an explanation tool. When stakeholders ask for early commitments:

• "At this stage, our estimates carry a 4× uncertainty range. We can tell you somewhere between 3 and 12 months."
• "After two months of work, we'll re-estimate with much less uncertainty."
• "To narrow the range now, we'd need to do specific learning work — which would cost time we'd otherwise spend building."

The framing helps stakeholders make decisions about whether to commit to a range, whether to invest in narrowing it through up-front discovery, or whether to defer commitment until more is known.

Coaching Tips

Show the cone to stakeholders.

The visual is more persuasive than any verbal explanation. A printed cone changes the conversation.

Don't commit to point estimates early.

"Between X and Y months" is honest. "X months" at concept stage is fiction.

Invest in learning to narrow the cone.

Spikes, prototypes, customer research. The cone narrows when learning happens.

Re-estimate at milestones.

After every major learning, re-estimate. Each refresh narrows the range legitimately.

Pair with Monte Carlo.

The cone is conceptual; Monte Carlo is quantitative. Together they communicate uncertainty in different forms.

Don't use the cone as an excuse.

"It's just the cone" can become a way to avoid commitment forever. Use the cone to explain, not to evade.

Summary

The Cone of Uncertainty is one of the most useful concepts for communicating estimation reality to stakeholders. By naming that early estimates are structurally uncertain — not the team's fault but the situation's nature — it sets the right expectations. The cone narrows over time only if the team actively learns; passive teams stay uncertain. Used as a communication tool rather than an excuse, the cone helps teams resist over-commitment at the start of work and re-commit honestly as understanding deepens.

Back to Flow & Forecasting