Estimating effort as a range with a stated confidence level

Goal

Produce estimates that tell the person asking how uncertain the answer is, so that decisions about deadline, budget or sequencing are made with that uncertainty in view.

Prerequisites

A record of past work items with their original estimate and actual duration (a ticket system usually has both), and agreement that an estimate is a forecast, not a promise.

Steps

1. Describe the work item as scope, not as a solution: what must be true when it is done. Estimates for undefined scope estimate the definition, not the work.
2. State three numbers: a best case in which nothing surprises you; a most likely value; and a worst case in which the known risks materialize. Lead time is often more useful than effort, because waiting time (reviews, dependencies, environments) can make up a large part of elapsed calendar time.
3. Phrase the confidence as a sentence: "80 percent sure it will be shipped within four weeks." A range without a confidence level is as ambiguous as a single point.
4. Calibrate against the reference class. Flyvbjerg's paper describes reference class forecasting: the forecast is based on the actual outcomes of a class of comparable past projects rather than on the plan of the current one, which avoids optimism bias and strategic misrepresentation. A team variant, offered here as a suggestion: take the last ten items of similar size, look at the ratio of actual to estimate, and widen the range enough that it would have contained most of them.
5. Name what would move the estimate: the two or three unknowns that decide between best and worst case, and how they can be resolved cheaply (a spike, a question to the owner of the dependency).
6. Record the estimate with a date. Update it at fixed points (after the first integrated slice, at every iteration boundary) and note what changed and why.
7. If a single number is demanded, give the one that fits the decision: the worst case for a commitment to customers, the expected value for capacity planning, and say which one it is.

Expected result

Estimates whose ranges contain the actual outcome about as often as the stated confidence claims; a visible history from which the team can correct its own bias.

Limits and test basis

Reference classes need enough comparable history; a first-of-its-kind project has none and should say so. Ranges invite people to quote only the best case; the record from step 6 is the defense. No calibration result is claimed here; the cited paper reports results for large transport infrastructure projects, not for software teams.