Status Droid how long software work actually takes

Reference-Class Estimating

Almost all good estimating is lookup, not modelling. This is like the thing we did in March, that took nine days, this one is a bit bigger, call it twelve.

The method has a name — reference-class forecasting — and a strong record. It beats analysis-from-first-principles for the same reason a doctor's pattern recognition beats a symptom checker: the base rates are in the examples. When this estimation problem needs an operational counterpart, read more offers a useful reference point.

It also stopped working for most people over the last two years, because it depends on your past resembling your present, and the workflow changed underneath it.

This page is about rebuilding it.

Why it broke, precisely

Reference-class estimating needs two things: a set of past instances, and confidence that they are comparable to the new one.

The instances survived. The comparability did not. A task from 2024 was done with a different workflow, in a different ratio of production to verification. Its duration is a fact about a process you no longer run. Thoughtworks publishes perspectives on delivery, engineering practice, and uncertainty See Thoughtworks Insights.

Worse, the change is not a constant you can adjust for. Some work got dramatically faster and some did not, so a single correction factor applied to your old reference class makes it wrong in a new way.

Rebuilding: the minimum viable class

You do not need years. You need enough recent instances to look up against, and "enough" is smaller than people assume.

Fifteen per bucket. Three buckets, so around forty-five tasks. At a normal working rate that is two to three months.

Recent, not comprehensive. Anything older than about a year is now of doubtful comparability. Deleting it is better than averaging it in.

Recorded, not remembered. The estimate must be written down before starting or the class contains your recollections, which are the thing being corrected for.

How to use it once you have it

Find the three closest past instances. Not the average of everything — the three most similar. Similarity means same bucket, comparable size, comparable familiarity with the system.

Take their actual durations, not their estimates. Obvious and routinely got wrong, because the estimate is what is written on the ticket and the actual is what you have to look up.

Adjust for the one or two ways this task differs. Explicitly and in writing. Like the export job in April, but the source data is unfamiliar, so up by a third.

Take the range across the three, not the middle. If they were 4, 6 and 11 days, your estimate is not 7. Your range is 4 to 11, and the 11 happened for a reason worth checking.

That is the whole method. It takes about five minutes and outperforms decomposition into subtasks, which produces confident-looking numbers by adding up guesses.

What to record so the class stays useful

Beyond the five basic fields, two annotations do most of the work at lookup time.

One line on what made it hard. Not a retrospective — a sentence. Most of the time went on the auth integration. Six months later this is what tells you whether a new task is comparable.

Whether it was the same kind of unfamiliar. New domain, new system, new ecosystem — these behave differently and a task that was hard for one reason is a poor reference for a task that is hard for another.

The awkward transition period

For the first two or three months you have no class, and estimating from the old one is wrong.

Use your pre-2024 instinct for the verification half unadjusted. That part changed least, and your old calibration is closest to correct there.

Discount the production half only in the cheap-to-verify bucket, and widen the range while you are unsure.

Say so, where the relationship allows. I am recalibrating my estimates after the workflow changes of the last two years, so this one has a wider range than I would normally give. Clients respond to this well, and it buys you the period you need.

Estimate anyway, and record it. An estimate you do not make cannot be wrong and also cannot be corrected. The class is built out of your mistakes, so the mistakes have to be recorded rather than avoided.

The property that makes it worth the effort

A reference class is the only estimating input that is yours. It does not depend on published averages, on vendor claims, or on which model is current. It is a description of what work actually costs when you do it, and it self-corrects — each new task both uses the class and improves it.

That is why it survives tool changes better than any technique, and why switching tools frequently is expensive in a way nobody counts: it is the thing that gets destroyed.

The short version