You were asked how long a feature would take, and you gave a number. Two weeks. You believed it when you said it. The feature shipped in five, and at no point could you have pointed at the moment it went wrong, because nothing went wrong in a single dramatic way. The estimate was just made at the worst possible time to make one: the beginning, when you knew the least about the work you were promising.

That is the idea behind the cone of uncertainty, and it is both more useful and more misunderstood than the one-line version every article gives you. The cone does not say your estimates are bad. It says there is a hard ceiling on how accurate any estimate can be at a given moment, and that ceiling is set by how much you still do not know. Early on, the range of honest outcomes is enormous. It narrows as you learn. The mistake almost everyone makes is assuming the narrowing happens automatically, on a calendar, just because time passed. It does not. You have to earn it.

What is the cone of uncertainty?

The cone of uncertainty describes how the range of possible outcomes for a project estimate shrinks as the project progresses and unknowns get resolved. Plotted over time, the best-case estimate and the worst-case estimate start far apart and converge toward the actual result as you approach completion. The shape is a cone: wide at the start, narrow at the end. Barry Boehm introduced the underlying data in his 1981 book Software Engineering Economics, and Steve McConnell popularized the "cone" name and refined the figures in his work at Construx.

(If you searched this term during hurricane season, there is a second, unrelated cone of uncertainty used in weather forecasting to show a storm's probable track. This article is about the software and project estimation concept, not the meteorological one.)

The number that makes people sit up is the spread at the very beginning. According to the figures Boehm and McConnell document, an estimate made at the initial-concept stage can land anywhere from a quarter of the eventual effort to four times it. A "two week" feature that is really a careful guess made on day one is honestly somewhere between three days and eight weeks, and you have no way to know which until you do some of the work. That is not incompetence. It is the math of estimating something you have not started.

If you keep your estimates and their eventual outcomes in one place, Scribelet can hold the original number next to what actually happened, which is the raw material you need to see your own cone instead of guessing at it.

How wide is the cone, really?

The value of the cone is that it puts numbers on "we are not sure yet." Here is the variance at each phase, drawn from the estimation research Boehm and McConnell published. The multipliers are the range around a correct estimate, so a 4x high end means the real effort could be four times your figure.

The cone of uncertainty: estimate variance starts at roughly a quarter to four times the real effort at initial concept and narrows toward one times as the project reaches completion

Project phase	Low end	High end	What you have actually learned
Initial concept	0.25x	4x	Almost nothing. You are estimating a sentence, not a design
Approved product definition	0.5x	2x	What you are building and roughly for whom
Requirements complete	0.67x	1.5x	The specifics of what the thing must do
Design complete	0.8x	1.25x	How you will build it, and where the hard parts are
Detailed design complete	0.9x	1.15x	The real shape of the work, edge cases included
Code complete	~1x	~1x	Everything. The estimate is now a measurement

Read down the "what you have learned" column and the cone stops being mysterious. The range does not shrink because the calendar advanced. It shrinks because each phase resolves a category of unknown. You cannot estimate the integration accurately until you have looked at the API you are integrating with. You cannot price the edge cases until the requirements name them. The accuracy is downstream of the knowledge, always.

This is why a demand for a precise estimate on day one is a demand to invent a number. The cone tells you the most honest answer is a range, and the range is wide. A team that commits to a single figure at initial concept is not being more confident. It is being less truthful about what it knows.

The part every definition leaves out: it is a best case, not a promise

Here is the distinction that separates people who understand the cone from people who have only seen the picture. The cone describes the best accuracy you can possibly have at each stage. It is a ceiling, not a forecast. McConnell is explicit about this at Construx: the cone represents the best case it is possible to achieve, and you only reach that best case if you are actively doing the work that removes uncertainty.

Skip that work and the cone does not narrow. You get a cloud. The project progresses, time passes, the calendar fills up, and your estimate is exactly as uncertain in week six as it was in week one, because nobody resolved anything. Requirements stayed vague. The risky integration got deferred instead of investigated. The "we will figure it out later" items were never figured out. The cone is a promise about what is possible, conditional on you earning it. It is not a guarantee that accuracy arrives on schedule.

This reframes the whole tool. The cone is not a passive prediction you watch come true. It is a to-do list in disguise. Every phase that narrows the cone corresponds to an act of uncertainty reduction: writing the technical spec so the requirements stop shifting, prototyping the scary part, pinning down the interface in a design document before you commit to a date. If your estimates are not getting more accurate as the project runs, the cone is telling you something specific and useful: you are not learning fast enough, and the deadline is arriving before the knowledge does.

Why your cone is not narrowing

When a project stays uncertain deep into its timeline, it is almost never a mystery. It is one of a handful of specific failures, and each one has a fix aimed at the unknown it leaves open.

Why the cone stays wide	What it looks like	What narrows it
Requirements never stabilized	The target keeps moving, so every estimate measures a thing that changed	Freeze scope in writing before estimating, and re-estimate explicitly when it moves
The risky work got deferred	The one genuinely uncertain piece is scheduled last, so the big unknown survives to the end	Do the scariest, least-understood task first; it carries the most uncertainty to resolve
No re-estimation	The day-one number is treated as a commitment and never revised as you learn	Re-estimate at each phase boundary; the cone is made of those revisions
Optimism instead of evidence	Each estimate is a hope about the best case, not a read on actual progress	Estimate from what comparable work really took, not from the happy path
Scope quietly expanding	The work grows as you build, re-widening a cone that was starting to close	Watch for feature creep; each small addition re-opens the range
Assumptions never written down	You cannot tell whether you estimated badly or reality changed, so you learn nothing	Record what each estimate assumed, so a miss teaches you which assumption broke

The through-line is that narrowing the cone is active work, and most of it is the unglamorous work of resolving ambiguity before it becomes a surprise. A team that does this looks, from the outside, like it is "just planning." What it is really doing is buying down risk one unknown at a time, which is the only thing that has ever made an estimate more accurate. The most direct version of this on a build is to front-load the risky integration with a thin end-to-end slice, resolving the biggest unknown in the first days rather than the last.

How to actually narrow it: re-estimate on a cadence

The practical move the cone implies is simple and almost nobody does it: re-estimate at every phase boundary, and write down both the new number and what changed to justify it. A single estimate made on day one is a guess. A series of estimates, each made with more information than the last, is a cone you can actually see closing, and each revision is a checkpoint where you can raise the alarm early if it is not.

Keep a short record per estimate. It costs a minute at each phase boundary and it is the only thing that turns the cone from a diagram into a skill.

Task/project: what you are estimating
Phase: concept | definition | requirements | design | build
Estimate: range (low to high), not a single number
Basis: what you now know that you did not know last time
Assumptions: the facts you are treating as fixed (libraries, APIs, people, scope)
Biggest remaining unknown: the one thing that would move the estimate most
Actual (when known): what it really took

The "biggest remaining unknown" line is the one that does the work. It names the widest part of your current cone, which tells you exactly what to investigate next to narrow it. Chase that unknown down before the next phase and the range closes on evidence instead of hope. This is the same discipline behind second-order thinking: an estimate is a prediction, and a prediction is only worth making if you can later check it against what happened and adjust.

The assumptions behind an estimate decay

There is a deeper reason the written record matters, and it is the reason most estimation advice quietly stops working a few weeks in. An estimate is a bet on a set of assumptions, and those assumptions expire.

When you estimated the work, you were assuming specific facts: this library behaves the way it did last quarter, this API is stable, this teammate is free, this requirement is final. Each of those can change between the estimate and the work, and when one does, your number is wrong for a reason that has nothing to do with your estimating skill. If you never recorded why you believed the estimate, you cannot tell later whether you misjudged the work or the ground moved under you. The estimate decays, and the reasoning behind it decays faster. This is the same knowledge decay that rots every other kind of working knowledge, and it is how a plan ends up quietly out of date while everyone still trusts it: the number survives, but the assumptions it was built on are gone.

This is where Scribelet fits. Its background agents re-check your notes and records against reality on a schedule and surface a diff when something no longer holds, so the assumptions behind an estimate do not silently expire while you are looking the other way. Your keys, your model, your data: the agents run on the provider you choose, and you see exactly what changed and why. Keeping the reasoning attached to the estimate is what lets the cone teach you something that carries to the next project. It is not a coincidence that the projects that blow up are the famous ones run by experienced teams. Research by Oxford's Bent Flyvbjerg found that one in six IT projects ran 200% over budget and nearly 70% over schedule, and that the damage clusters in a fat tail of catastrophic overruns. Those teams were not short on expertise. They were short on a closing cone, committing to numbers that the work had not yet earned. It is Hofstadter's Law at the scale of a whole project: the work takes longer than you expect, even when you expect it to, because the cone never closed enough to catch the overrun in time.

Getting started

The cone of uncertainty is not a problem to solve. It is the permanent shape of estimating things you have not finished, and the goal is to work with it instead of pretending you are above it.

Do three things. Give ranges, not single numbers, and make the range honest: early on it should be wide, because the cone says it has to be. Re-estimate at every phase boundary and treat the narrowing as a result you earned by resolving unknowns, not a gift the calendar hands you. And write down the assumptions behind each estimate, because the estimate that misses almost always misses on an assumption that quietly stopped being true. Try Scribelet free and let it keep the reasoning behind your plans current, so each estimate inherits what the last one learned instead of starting the cone over from scratch.