The cone of uncertainty
Early estimates are wide because the work is unknown — not because your team is bad at estimating. The cone is a license to give a range, not a reason to pad.
The cone says your earliest estimate is your worst one — and that's a property of the work, not a flaw in the team. Stop demanding a single number for something nobody has started.
The cone of uncertainty 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.
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; 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 to either resolve the uncertainty (spike, refine, split) or to communicate the range honestly and commit to re-estimating, not to inflate a single number until it feels safe. Uncertainty is information; a padded point estimate throws it away.
The earliest estimate is the widest. Narrow the cone by learning, not by padding — and never hand a point estimate to a question that deserves a range.
Common questions
What is the cone of uncertainty?
The cone of uncertainty describes how the range of a project estimate is widest at the start and narrows as the work progresses and unknowns get resolved. Early on, an estimate can be off by a factor of several 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 popularized it in agile and software estimation circles.
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, so they 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 team stops asking questions, 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.
Adjacent: relative vs absolute estimation for why relative sizing survives the cone; re-estimating story points for what to do as it narrows; what is a spike for buying the information that shrinks it.