Estimating work as a range with a stated confidence

Goal

Produce estimates that tell the person asking how uncertain the answer is, so that a deadline, a budget or a sequencing decision can be made with the uncertainty in view.

Prerequisites

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

Steps

1. Describe the item as a scope, not a solution: what has to be true when it is done. Estimates for undefined scope are estimates of the definition, not of the work.
2. Give three numbers: a best case that assumes nothing surprises, a most likely value, and a worst case that assumes the known risks happen. Elapsed time is usually more useful than effort, because waiting (reviews, dependencies, environments) often makes up most of the calendar time.
3. State the confidence as a sentence: "80% confident it ships within four weeks." A range without a confidence is as ambiguous as a point.
4. Calibrate against the reference class. Flyvbjerg's paper describes reference class forecasting: base the forecast on the actual outcomes of a class of comparable past projects instead of on the plan for this one, which bypasses optimism bias and strategic misrepresentation. A team-scale version, proposed here: take a set of past items of similar size (the last ten, say) and look at the ratio of actual to estimated; widen the range until it would have contained most of them.
5. Name what would move the estimate: the two or three unknowns that decide whether it is a best or a worst case, and how they can be resolved cheaply (a spike, a question to the owner of the dependency).
6. Record the estimate with its date. Revise at fixed points (after the first slice is integrated, at each iteration boundary) and note what changed and why.
7. When a single number is demanded, give the one that matches the decision: the worst case for a commitment to a customer, 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 says; a visible history that lets the team correct its own bias.

Limits and test basis

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