Most arguments about software estimates are really arguments about three different things wearing the same word. An estimate is a probabilistic assessment of how long something will take. A target is a business objective. A commitment is a promise to hit a date. Steve McConnell’s 17 theses on estimation hang on keeping these separate: the job of estimation is not to predict the outcome but to decide whether a target is realistic enough that the project can be steered to meet it. This note is a practical guide to that steering: the techniques for producing a number, why the number is always a range, and how to forecast delivery when the estimate itself is untrustworthy.
The cone, and why time alone does not narrow it
Barry Boehm measured it at TRW in the early 1980s and McConnell named it: the Cone of Uncertainty. At the moment a project is first conceived, before anyone has decided what “done” means, estimates are accurate to within a factor of about 4x in either direction. That is a 16x spread between the low and high plausible outcome for the same project. The cone narrows as the project proceeds, to roughly 1.6x after requirements, tighter after design, converging on the actual only near the end. Treat the exact multipliers as a model, not a measured law. Laurent Bossavit’s Leprechauns of Software Engineering argues the original data never demonstrated the clean cone shape it is drawn with, and the numbers are better read as illustrative than empirical.
The part everyone skips: the cone does not narrow on its own as the calendar advances. It narrows only as you resolve the decisions that create the variance. Pin down scope, kill the ambiguous requirement, choose the architecture. A team that has been coding for three months but never nailed down what it is building sits in the same fat part of the cone it started in. The cone is the best case accuracy at each stage, not a schedule that reduces uncertainty for you. Left alone it is a cloud, not a cone.
The techniques, cheapest to most defensible
Expert judgment and analogy. Ask someone who has built the thing before, or find the closest past thing and adjust. Fast, and better than its reputation when the expert has real reference cases. It fails silently when this project only looks like the past one.
Decomposition. Break the work down until each piece is small enough to reason about, estimate the pieces, sum them. The catch is that errors do not cancel the way you hope. If your misjudgments are correlated, decomposition sums the bias instead of averaging it out. And they usually are correlated: one optimistic assumption about the codebase infects every task. It also systematically omits work nobody thought to list.
Planning poker. James Grenning invented it around 2002; Mike Cohn popularized it in 2005. Everyone estimates a backlog item simultaneously on a modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20), then the outliers explain themselves and the group re-votes. The Fibonacci gaps are deliberate: the values sit far enough apart to be distinguishable, often justified by appeal to the Weber-Fechner limit on perceiving relative magnitude. The simultaneous reveal is the real mechanism. It blocks the anchoring that happens when the loudest or most senior person estimates first.
Three-point (PERT). Instead of one number, give three: optimistic, most likely, pessimistic. The PERT expected value weights the middle, (O + 4M + P) / 6, and the standard deviation is (P − O) / 6. The output is not a point but a distribution, which is the honest shape of the answer. Its weakness is that people generate the three numbers by nudging up and down from a single gut estimate, so the “range” inherits the same anchor and is far too narrow.
Notice the trajectory: every technique that improves on the last does so by refusing to collapse the answer into a single number too early.
Story points measure size, not time
Story points are relative effort, deliberately unitless so teams stop pretending they can predict clock time. The trouble starts when they are treated as time anyway. Mine the data and the correlation is weak to absent. Practitioners pulling historical issue data repeatedly find 1-point items ranging from under a day to three weeks, with the same wide spread at 5 points, and some analyses of multi-year project data find no correlation between points and cycle time at all. Smaller-pointed items sometimes finish after larger ones.
This is not a failure of story points. It is a category error in how they are read. A point estimate captures complexity and effort at the moment of estimation. Elapsed time is dominated by things points never encoded: how long the item waited in a queue, how often it was blocked, how much work-in-progress it competed with. Which is why the more predictive signal is not the estimate at all but the flow. Count how many items a team finishes per week (throughput), keep the count honest by capping work in progress, and you have the input for a real forecast.
Reading the tea leaves: forecast, don’t estimate
The shift that makes prediction tractable is giving up on the single date and producing a probability distribution over dates. Two methods dominate.
Monte Carlo from throughput. You have a backlog of N remaining items and a history of weekly throughput. Instead of estimating the items, simulate the future by resampling the past: draw a random week’s throughput from your history, subtract it from N, draw again, and count weeks until N hits zero. That is one trial. Run it a few thousand times and you get a full distribution of completion dates. Sort them and read off percentiles. The 50th is a coin flip. The 85th is the number you commit to, the date you beat 85% of the time. The method never estimates a single item. It lets the natural variation in your own delivery history stand in for the size of the work, which is exactly the size story-point estimation tries and fails to pin down. Re-run it every week or two, because a forecast from a 10-person team’s history is worthless the moment the team is 5 people.
This is where estimation and forecasting rejoin McConnell’s frame. A target is realistic when it sits at or beyond the date you are willing to commit to, the 85th percentile of the distribution. If the target lands at the 30th percentile, the number is not telling you to try harder, it is telling you to renegotiate scope or the date. The distribution adjudicates the target; it does not just describe the work.
Reference class forecasting. Zoom out from tasks to whole projects and use the outside view: predict this project from the recorded outcomes of similar finished projects, not from its own plan. This is the antidote to the planning fallacy, the reliable one-way skew where estimates lean optimistic even after you have personally watched comparable work run long. Tetlock’s superforecasters do the same thing under the name “comparison classes,” and the discipline that separates them is starting from the base rate before touching case-specific detail.
The base rates are grim enough to be useful. Flyvbjerg and Budzier’s study of 1,471 IT projects found an average cost overrun of 27%, which sounds survivable until you look at the shape of the distribution. It is fat-tailed: one project in six was a “black swan” with a cost overrun averaging 200% and a schedule overrun near 70%. The mean hides the risk. Planning against the average is planning against a number that will not describe the project that hurts you.
The tells
What to watch for when someone hands you an estimate, including your own.
- A single number is a lie of omission. No range means no expressed uncertainty, which means the estimator either doesn’t know the spread or is hiding it. Ask for the 90% case.
- Check the skew, not the average. Pull your last ten estimates, divide actual by estimate, take the median. For most people it lands above 1, often well above. That one-way lean, the ratios clustering above 1.0 instead of straddling it, is the fingerprint of bias rather than noise, and it is your personal multiplier.
- Padding evaporates. Buffers hidden inside individual task estimates get consumed by Parkinson’s Law and the student syndrome, then vanish when they would have helped. Critical chain pulls the safety out of every task and pools it into one shared project buffer you can actually see being burned.
- Separate the estimate from the negotiation. When a number moves because a deadline was announced, that is not a better estimate, it is a target wearing an estimate’s clothes. And when overruns are systematic rather than random, suspect strategic misrepresentation: the low bid that wins approval is not always an honest mistake.
- Some work cannot be estimated, only bounded. In the complex domain of the Cynefin Framework, where cause and effect are clear only in hindsight, the right move is a timeboxed probe, not a point estimate. Forecasting genuinely novel work as if it were known work is the most expensive mistake on this list.
Try it
Build a Monte Carlo forecast from your own history (2-3 hours, any spreadsheet or Python). Export the last 12+ weeks of completed-items-per-week for a team or your own work. Write a loop: pick a random week’s count from that history, subtract from your remaining backlog size, repeat until you hit zero, record the number of weeks. Run it 10,000 times, sort the results, and read off the 50th, 85th, and 95th percentiles. Compare the 85th-percentile date to whatever single-date estimate you would have given by gut. The gap between them is the uncertainty you were about to promise away.
Find your planning-fallacy multiplier (1 hour). Take 8-10 past tasks where you recorded an estimate and an actual. Divide actual by estimate for each, take the median: that is the factor to multiply future gut estimates by. Then look at the spread. If the ratios cluster above 1.0 instead of straddling it, you have measured your own optimism bias directly, in your own data.
See also
- Cynefin Framework — when the work is complex rather than complicated, estimation is the wrong tool and probing is the right one
- Throughput Accounting — the flow-based thinking that makes throughput forecasting more than a metric
Sources
- McConnell, “17 Theses on Software Estimation” — the estimate/target/commitment distinction and the purpose of estimating.
- McConnell, “Software Estimation’s Cone of Uncertainty” — the 16x-to-1x narrowing and the point that it narrows only as decisions are made.
- Flyvbjerg & Budzier, “Why Your IT Project May Be Riskier Than You Think” (HBR 2011) — the 1,471-project sample, 27% mean overrun, and the fat-tailed black-swan risk.
- “Do Story Points Work?” (Jellyfish) and “The Story Points Illusion” (agility-at-scale) — the weak-to-absent correlation between points and elapsed time.
- “Monte Carlo Simulation Explained” (Nave) and “What Monte Carlo Is and Isn’t” (ProKanban) — the resample-throughput procedure and reading commitments off the 85th percentile.
- Three-point estimation (Wikipedia) — the PERT expected-value and standard-deviation formulas.