A reference class of one: why "by Thursday" is a genre of fiction

Think about the last time you renovated a kitchen, or watched a friend do it. The contractor said six weeks. It took eleven. Nobody involved was lying, incompetent, or even particularly unlucky — eleven weeks is, roughly, what kitchen renovations actually take, and six weeks is, roughly, what kitchen renovations sound like they should take to someone standing in the empty room imagining the happy path.

Now translate that into your standup, where a perfectly competent engineer says "I'll have the timeout fix in charge() by Thursday," and means it completely.

The bias that has a name and a paper

Daniel Kahneman and Amos Tversky named this in 1979, in a paper called "Intuitive Prediction: Biases and Corrective Procedures," and the mechanism they described has not needed updating since: when people forecast how long something will take, they construct a scenario — usually something close to the best case — and then report that scenario's duration as the estimate, systematically discounting the much larger space of ways the plan could go sideways. It isn't dishonesty. It's a structural feature of how forecasting-by-imagining works: you can vividly picture the plan succeeding. You cannot vividly picture the specific unknown thing that will derail it, because if you could picture it specifically, you'd have already planned around it.

Kahneman later worked this into a sharper distinction with Dan Lovallo: every forecast can be made from an inside view — focusing on this specific case, this plan, this team, this Thursday — or an outside view — ignoring the specifics entirely and asking how long things like this have actually taken before. Their finding, and it's an uncomfortable one: the inside view is almost always more vivid, more persuasive, and more wrong. People trust it anyway, because it feels like it's accounting for the details that make this case special, when what it's actually doing is excluding the base rate that would have humbled it.

Three thought experiments to run on your own sprint

1. Pull up the last ten "I'll have this by [day]" commitments your team made in standup. Don't look at whether they were right or wrong yet — just look at whether anyone, at the moment of saying it, cited a single data point about how long similar work had taken before. Almost never happens. The estimate was generated from the plan, not from history.
2. Now find the three that landed late. Ask what specifically went wrong. In our experience running this exercise, the answers cluster hard around a small set of repeat offenders — an unfamiliar test suite, a review queue nobody accounted for, a dependency that always turns out messier than it looks — the exact "known unknowns" an outside view would have priced in and an inside view, by design, excludes.
3. Ask the person who made the original estimate whether they'd have estimated differently if you'd shown them, in advance, "the last five changes to this function took a median of 9 days, not 2." Almost everyone says yes. Almost nobody had that number available at the moment they needed it.

Reference class forecasting: taking the outside view seriously enough to build a method

Bent Flyvbjerg took this insight and did something almost nobody does with a cognitive bias: he turned it into a formal forecasting procedure and got governments to actually use it. Reference class forecasting works by refusing to estimate the specific project directly. Instead: identify a class of genuinely comparable past projects, get the actual distribution of outcomes for that class, and place your project somewhere in that distribution rather than inventing a number from scratch. Flyvbjerg's own account of curbing optimism bias in planning documents this being adopted for real infrastructure — UK transportation projects including the Edinburgh Tram and the multi-billion-pound Crossrail scheme — specifically because inside-view estimates for megaprojects had been wrong, in the same optimistic direction, for decades, predictably enough that "predictably wrong" became the actual finding.

Software estimation has no Crossrail-scale forcing function, which is precisely the problem — a late tram gets a public inquiry; a late ticket gets a shrug and a new Thursday. But the mechanism Flyvbjerg is exploiting is not specific to civil engineering. It's specific to the fact that a class of comparable past attempts, honestly measured, is a better predictor of the future than a fresh imagination of it every single time, in every domain anyone has bothered to check.

A reference class of one is not a forecast. It's a guess wearing a deadline, and the deadline is doing all the work of making it sound like a forecast.

Why "by Thursday" is structurally a reference class of one

Here's the sharpest way to say what's actually wrong with the standup estimate: it is, almost always, a forecast built from a reference class of exactly one member — this specific plan, imagined once, by the person who wants it to be true. Compare that to what a reference-class forecast would require: "the last N changes to this function, made by this team, took a median of X days, with a long tail out to Y." That number already exists, sitting quietly in the commit history, completely indifferent to how anyone feels about Thursday. Almost nobody pulls it before making the commitment. Almost everyone could.

None of this means estimates are worthless, or that anyone should stop making them — a standup with no commitments is a standup with nothing to check. It means a commitment should be treated, honestly, as a claim with a horizon, not a promise with a vibe: resolved later by whether a commit touching the named subject actually landed before the date, not by how confident the sentence sounded when it was said. Which, per the last three parts of this series, is the only kind of evidence that was ever going to be honest anyway.

The fix costs one sentence

You don't need Flyvbjerg's full methodology to get most of the benefit. Before the next "I'll have it by Thursday," ask one outside-view question: "how long did the last similar change to this actually take?" If nobody knows, that's the finding — the team is estimating from imagination because the alternative was never made easy. If someone does know, and it doesn't match the new estimate, you just moved a piece of information from "buried in the commit log" to "priced into the plan," for the cost of one sentence, before the deadline instead of after it.