The cone of uncertainty in agile estimation

Early estimates are wide because the work is unknown, not because your team is bad at estimating. What the cone of uncertainty means, and how to narrow it — not pad it.

Your earliest estimate is your worst one — and that’s a property of the work, not a flaw in the team. The cone of uncertainty is the reason to stop demanding a single number for something nobody has started.

The cone is a simple observation with sharp consequences: at the start of a piece of work, the spread between your estimate and reality is enormous, and it narrows as you learn. Barry Boehm spotted the shape in software-cost data; Steve McConnell named it. Plotted over time it looks like a cone — wide on the left, where you know least, collapsing toward a point on the right, where the work is nearly done and there’s nothing left to be wrong about.

The cone of uncertainty narrowing over time estimate range wide early narrows to a point Project start time →
The spread is widest before you start and collapses as you learn. The estimate isn’t wrong — it’s early.

Why it matters for estimation

Most estimation pain comes from demanding a point estimate at the widest part of the cone. Someone asks “how long will the new billing system take?” before a line is written, gets “about three months,” and treats it as a commitment. The cone says that number is honestly somewhere between six weeks and nine months — and pretending otherwise just relocates the disappointment to later.

This is the whole reason agile estimates relative size instead of committing to dates. Story points and planning poker don’t fight the cone — they accept it. A quick relative read (“this is bigger than the thing we shipped last sprint”) is the honest amount of precision available early, and velocity turns that into a forecast with a range rather than a false promise.

How to narrow the cone

The cone narrows when you remove unknowns — not when you add buffer. In order of leverage:

  • Spike the riskiest unknown. A time-boxed spike buys information, which is the only thing that actually shrinks the range.
  • Refine until the questions stop. A story the team keeps asking questions about is sitting at the wide end of the cone; sharp acceptance criteria drag it rightward.
  • Split it. Smaller stories sit further down the cone — each piece is understood, so each estimate is tighter than one estimate for the whole.
  • Re-estimate when you’ve learned something. Re-estimating as the cone narrows is honest; doing it to chase a target is not.

The cone is not an excuse to pad

The wrong lesson is “everything’s uncertain, so double every estimate.” Padding moves the whole cone up without narrowing it — you’re still guessing, just pessimistically. The right response to a wide cone is either to resolve the uncertainty (spike, refine, split) or to communicate the range honestly and commit to re-estimating.

Frequently asked questions

What is the cone of uncertainty?

The cone of uncertainty describes how the range of an estimate is widest at the start of a piece of work and narrows as the work progresses and unknowns get resolved. Early on, an estimate can be off by a large factor in either direction; by the time the work is well understood, the range collapses toward the actual result.

Who came up with the cone of uncertainty?

The shape was first observed by Barry Boehm in the early 1980s as a software-cost relationship, and Steve McConnell later named it the “cone of uncertainty” and popularised it in agile and software estimation.

How does the cone of uncertainty apply to agile estimation?

It’s the reason agile estimates relative size rather than committing to dates up front. Story points and planning poker accept that early estimates are wide, trade false precision for a quick relative read, and re-estimate as the cone narrows through refinement, spikes and shipped work.

How do you reduce the cone of uncertainty?

You don’t pad it — you resolve the unknowns that make it wide. Run a spike on the riskiest part, refine the story until the questions stop, split it so each piece is understood, and re-estimate once you’ve learned something. The cone narrows when uncertainty is removed, not when the number is inflated.