Skip to content
Log in
← Glossary

reference class forecasting

Also called: reference class

Estimating a new project from how long and how much similar past projects actually took, then adjusting for what is truly different. It corrects the optimism of building the plan only task by task.

Reference class forecasting estimates a new project from how long and how much similar past projects actually took, not from a fresh task-by-task build-up. It is the practical answer to the planning fallacy: the inside view (your plan) feels convincing, the outside view (the record) tells you how plans like yours usually end.

The method has three steps. First, choose the reference class: past projects or tasks that are genuinely similar in kind, size and team, and say why you chose them. Second, look at how they went: the ratio of actual to estimate, or the spread of actual durations and costs. Third, place the new project in that distribution, then adjust only for differences you can name and check. "We have learned our lesson" is not a difference; "the reviewer has already read half the draft" is.

The choice of class matters most. Too broad, and you average unlike things (a platform build with a curriculum launch); too narrow, and two data points decide everything. Compare like with like as well: if the past estimates were padded and your new ones are not, use the overrun of unpadded estimates.

It needs data you can only collect yourself: for each task, the estimate, the actual and whether the estimate already held a margin. A short table filled in at every retrospective is enough to start.

Example

On 30 November the physics launch has 43 working days to 29 January, and the chain to opening adds up to 32 days at the owners' most likely values. Klasna has logged three earlier launches:

  • all three launches: 142 days estimated, 168 actual (× 1.18);
  • the math exam simulator was mostly a platform build, so the closer class is the two subject launches (curriculum, review, demo lessons, onboarding, like physics): 93 estimated, 113 actual (× 1.215);
  • within them, the tasks whose estimates held no private margin: 50 estimated, 67 actual, 67 ÷ 50 = × 1.34.

The new most likely values are unpadded, so the unpadded ratio fits: 32 × 1.34 = 42.88 working days against 43 available. The inside view said 11 days of buffer; the outside view says almost none.

The same move on one task: the three expert reviews in the record took 27 days against 16 estimated (× 1.6875). Vira's review, likely 6 days, becomes 6 × 1.6875 = 10.13 days, against an expected 7 from her own three-point estimate. That is the task to watch first, and the reason to agree on a second reviewer early.

Common mistakes

  • A class that is too broad. Mixing a platform build with curriculum launches blurs the ratio you need.
  • Adjusting for hope instead of facts. Only named, checkable differences justify moving away from the record.
  • Mixing padded and unpadded estimates. Apply the overrun of estimates made the same way as your new ones.
  • Using the outside view once and forgetting it. Check the forecast again as the work goes and the class grows.
  • Having no record to draw on. Log the estimate, the actual and any hidden margin at every retrospective.

Learn it in the course

  • Case: estimates versus actuals · Use three earlier Klasna launches and the three-point estimates of the chain to tell Leo whether physics can open on 1 February, and how sure you are.
  • Past projects as a reference, and one shared buffer · Why padding every task makes the date absurd and still finishes late, how earlier launches correct your optimism, and how one buffer under the lead replaces hidden margins.