Estimates you can defend

An estimate that turns out to be wrong is usually treated as a failure of judgement, which is why the standard remedies are all about the estimator — be more careful, break it down further, remember last time. The measured behaviour of software estimates says something else: most of the error was already present in the situation before anybody was asked, and it is a property of what has not been decided yet.

What people actually want to know is narrower than the question they ask. They gave a number, the number was wrong by a lot, and they cannot tell whether they were unlucky, careless, or set up.

The range is measured, not imagined#

Steve McConnell’s Cone of Uncertainty puts numbers on it. At initial concept — when the project is a description and not much else — an estimate can be off by a factor of four in either direction: four times high, or a quarter of the real figure. That is a total spread of sixteen between the optimistic and pessimistic ends of the same honest estimate.

The cone then narrows in steps, and each step is a class of decision being made rather than a period of time going by.

Two things in that table are worth more than the numbers. The first is that even at the far right, with the design finished, the spread is still around 1.6 — an estimate given after every design decision has been taken can still be a quarter out, and treating that as a personal failing is treating physics as a character flaw. The second is what the left-hand column is made of. Every row is a set of questions being answered. None of them is “the team tried harder” or “the estimator had more experience”.

What actually narrows it#

The part of McConnell’s argument that gets dropped when the picture is reproduced is the important half: the Cone does not narrow itself. It shows the best accuracy that is available at each stage, on the condition that the variability has actually been removed by somebody making the decisions. A project where the requirements are still being reinterpreted in month four has not moved along the cone at all, whatever the calendar says. He has a name for that state — the Cloud of Uncertainty — and the point of the name is that it looks identical from the inside to being early in a project that is going fine.

This changes what a defensible estimate contains. A single number asserts a position on the cone that you usually cannot justify. A range plus the question that would collapse it asserts something you can: three days if the old accounts use the same identifier, closer to three weeks if they do not, and half a day to find out which. That form does three things a number cannot. It is falsifiable, so it can be checked rather than believed. It hands back a decision rather than a guess, which is what the person asking actually controls. And when it turns out to be three weeks, the record shows the condition was named in advance, which is the difference between a miss and a surprise.

It also explains why estimating feels worse on some teams than others for no visible reason. If the decisions above yours are not being made, no amount of care at your level moves you rightward along the cone, and every estimate you give will be wrong by roughly the amount the situation guarantees.

Why four tasks drift the same way#

There is a comforting intuition about breaking work down: split a project into twenty pieces, get each one a bit wrong in a random direction, and the errors cancel. That is true, and it is true only under two conditions that software estimates almost never satisfy.

The first condition is independence. Errors cancel when they have unrelated causes. Estimates on one project share their causes almost completely — the same person, the same missing information, the same unexamined assumption that the data is clean, the same picture of the system in everybody’s head. When that picture is wrong, it is wrong in all twenty estimates at once, and there is nothing to cancel against.

The second condition is symmetry, and this one cannot be fixed by involving more people. A task estimated at two days can take twelve. It cannot take minus eight. The overrun has room to run and the underrun does not, so the average outcome sits above the estimate even when every individual guess was made in good faith. Twenty tasks with a long tail on one side and a wall on the other do not average out; they accumulate in the direction the tail points.

Add ordering to that and the last defence goes. When task three cannot start until task two finishes, an overrun does not stay inside its own box — it moves everything after it, and the schedule inherits the sum of the delays rather than their average. This is the same accounting that makes the true cost of getting one change merged so much larger than the time spent writing it: what dominates is not the work, it is everything that has to wait on the work.

Where it goes wrong#

The damaging failure is not the estimate that was too low. It is the range that got collapsed in the corridor between the person who gave it and the person who wrote it down.

The sequence is dull enough to be invisible. An engineer says three to eight days. A manager needs one number for the plan, so it becomes five, reasonably, because five is the middle. The plan is shared and five becomes “the estimate”. A week later someone reads the plan, sees a five-day task, and schedules a dependent piece of work to start on day six. Nothing dishonest happened at any step, and the conditional has been laundered into a commitment that no longer names the condition it depended on.

What makes this expensive is that the failure is unattributable afterwards. When day eleven arrives there is no artefact showing that a range was given, so the conversation is about whether the engineer estimates badly. The engineer, who remembers saying three to eight, experiences the conversation as dishonest and starts padding — which is the beginning of the pattern where every number on the team is quietly inflated and nobody can plan with any of them.

The remedy is small and has to be done at the moment of giving the estimate, because there is no later opportunity. Write the range down where the plan lives, with the condition attached, in one line. A comment on the ticket is enough. The point is not ceremony or self-protection — it is that the condition is the part carrying the information, and it is the part that gets dropped first when a number travels through an organisation.

The second failure is the reverse and belongs to the person receiving the estimate: treating the number as a negotiation. An estimate met with “can you make it three?” gets a yes, because the alternative is an argument, and the yes changes nothing about the work — it only moves the moment of discovery to the end. Pushing back on this is a specific skill of its own, and it is the same one needed for making a case against a decision you do not own: the disagreement has to be about the facts of the situation rather than about who is being difficult.