Cone of Uncertainty

For a long time nobody asked when an estimate had been given. Engineering said roughly three months at the kickoff meeting, the number went into the notes, moved onto the roadmap, and became the date sales quoted to customers. Then the fourth month arrived with the work unfinished, and whoever said three months was the person who broke a promise.

That person usually has a case. Three months was everything the kickoff meeting made knowable. How many screens there would be, whether an outside payment provider had to be integrated, whether existing data needed migrating — none of it was decided when the number came out. Ask the same person two months later and the answer is far more accurate. Nothing improved about the person; more things had simply been decided.

Pagedeck lived this. Grace asked at a board meeting when enterprise permission controls would ship, and Mia said roughly three months. That number went into the investor deck the same day, and two months later, once the integration scope became visible, it turned into five. When Grace asked why it had nearly doubled, what Mia needed wasn't an excuse. It was a way to explain which point in the work the three-month number had come from.

The cone puts progress through the work on the horizontal axis and the ratio of estimate to actual outcome on the vertical one. The left edge is the start, before anything is settled; the right edge is completion. At the left the spread above and below is wide, and it narrows toward the right until it converges on the single number the work actually took. Drawn out, it looks like a cone lying on its side.

The width has rough numbers attached to it.

1. At the start, with only the idea of what to build settled, the real duration lands somewhere between a quarter and four times the estimate. Say three months and the truth might be three weeks or a full year.
2. Once requirements are fixed and design is finished, the spread tightens to roughly 0.8 to 1.25 times. Say three months there and the range runs from two and a half to four.
3. Once about half the work is built, the error on what remains gets smaller still, because the team has now done something similar on this codebase.

The part most often missed is that the cone doesn't narrow by itself. What reduces the width isn't elapsed time but the decisions made during it. Settle the list of screens, choose the payment provider, decide whether the data gets migrated, and it narrows by that much. Spend three weeks deciding nothing and the width is exactly what it was, with three fewer weeks left.

Which leaves two practical uses for the model. One is giving a range instead of a single number. The other is recording when the number was produced. Saying two to five months is more honest than saying three, and the person hearing it can look at that spread and judge whether this is a decision that can be made today.

The widest part of the cone is quarterly and annual planning. Dozens of pieces of work sit there unbroken-down while the order gets decided, so precise figures aren't available. Sorting them into rough grades like S, M, and L with t-shirt sizing isn't a compromise on precision — it's the precision that exists at that point in the cone.

The narrow part is planning a single cycle. Items with settled requirements get sized against a reference item through relative estimation, written down in an addable unit such as story points, and checked against velocity, the average the team has actually finished recently, so the cycle takes only what fits. Numbers produced here carry different weight from numbers in the quarterly plan, even when both appear in the same roadmap document.

The distinction matters for outside commitments too. When Sofia has to give a customer a date at Pagedeck, anything in the wide part of the cone gets a quarter rather than a date, plus a promise to come back with something firmer once design is done. Anything in the narrow part gets a date.

The last use is a rhythm for re-estimating. The cone is worthless if estimation happens once. Each time something gets settled the width has shrunk, so a commitment to update the number has to come with it. Pagedeck picked the end of design as its update point.

"We're at the wide end of the cone, so I can't commit to three months. I'll give you two to five."

An answer given as a range, and at the same time a signal not to turn it into an external commitment.

"I'll re-estimate once design is done. The spread is much tighter by then."

A proposal to set an update point instead of straining to make today's number exact.

"That figure is from kickoff. You're still working off it?"

Pointing out that the document never followed the cone as it narrowed.

Pagedeck's roadmap document now carries, next to each feature's number, the point in the work when that number was produced. Meetings changed shape after Mia added the column. Grace used to ask why three months had become five; now the first thing she checks is whether a figure is a kickoff number or a post-design one. Kickoff numbers mean the spread is still wide, so the investor deck gets quarters rather than dates.

The most common reading is that the cone narrows on its own as time passes. The horizontal axis is time, so the assumption is a fair one. But what closes the spread is the unknowns that got resolved, not the weeks that went by. Spend two months without fixing requirements and you reach the deadline with exactly the spread you started with. Left uncorrected, a team waits instead of deciding and discovers two weeks before the deadline that the schedule was off by double.

The second is using the model as cover for being wrong. It does say the error can run to four times, which reads like permission. What the cone asks for, though, is that the spread be stated, not excused. Saying three months and missing is a different act from saying two to five and landing inside it. Once a team starts using the cone as a shield without ever publishing the range, listeners stop believing the numbers — and from that point a range doesn't help either.