The Estimate Playbook: give a date that actually holds

You are asked how long something will take. You think about it honestly, you say six weeks, and it takes eleven. Then you apologise, and everyone agrees the work was harder than expected, and next time you say six weeks again.

This is the single most expensive recurring failure in professional work, and it is not a character flaw. It is a predictable output of how humans estimate: we imagine the version of the task where nothing goes wrong, because the things that go wrong have not happened yet and therefore are not available to imagine. Psychologists call it the planning fallacy. The fix is not to try harder or be more pessimistic. Pessimism is just a different guess.

The fix is to stop generating estimates from your imagination and start generating them from your history. Here is the system.

Step 1: Find the reference class before you think about the task

Do this first, before you decompose anything, before you open a project plan, before you let yourself picture the work at all. The moment you start imagining the task, you are anchored.

Ask one question: what are the last five things I did that were roughly this shape, and how long did each actually take, start to finish, on the calendar?

Note the three constraints in that sentence. Roughly this shape, not identical — you will never have five identical projects, and waiting for a perfect match is how people talk themselves back into guessing. Actually took, not what you estimated. Start to finish on the calendar, not hours of effort. If you started on 3 March and shipped on 28 April, that is eight weeks, even if you only touched it on Tuesdays.

Then take the median of those five numbers. That is your first estimate. Not your final one — your first. You have now produced a number that contains every category of thing that has historically gone wrong, without needing to predict which one will go wrong this time.

Most people's reaction to their own reference class is that it feels too long. That feeling is the planning fallacy arguing with you. It is not new information.

Step 2: Decompose only into pieces you have shipped before

Now you are allowed to look at the task. Break it into chunks — but the test for a valid chunk is not "is this small" or "is this logically separate." It is: have I personally finished something like this before, and do I know what it took?

Any chunk that fails that test is not an estimate item. It is a research item, and research items do not get durations. They get timeboxes.

The distinction matters enormously. "Build the reporting page" is an estimate item if you have built four reporting pages. "Work out whether their API can give us the data at all" is not an estimate item no matter how confident you feel, because the honest answer is somewhere between two hours and never. Give it a timebox — "three days, then we decide" — and make the decision point a real event on the calendar with a name attached.

A plan that is 80% estimate items and 20% timeboxed unknowns is a plan. A plan that is 100% estimate items is a work of fiction, and everyone reading it can feel that even if they cannot say why. If the chunk list keeps growing after you have written it down, you do not have an estimating problem — you have a scope problem, and that is a different fix.

Step 3: Estimate three numbers, then use the one you did not want

For each estimate item, write three durations:

• Best case (B): everything goes right, nobody is sick, the dependency arrives on time.
• Likely case (L): the ordinary version.
• Worst realistic case (W): not the apocalypse. The bad-but-plausible version you have actually lived through.

Then compute (B + 4L + W) ÷ 6. This is a weighted average that has been used in project scheduling for decades, and its value is not mathematical sophistication — it is that it forces you to write W down. People who estimate one number never think about the bad case at all. People who estimate three cannot avoid it.

Worked example, a two-week feature:

• Best 6 days, Likely 10 days, Worst 22 days → (6 + 40 + 22) ÷ 6 = 11.3 days

Eleven and a bit, against a "likely" of ten. That gap looks trivial on one item. Across nine items it is three weeks, and three weeks is the difference between a team that hits dates and a team that does not.

Step 4: Apply your own error ratio, not a generic buffer

Here is the step almost nobody does, and it is the one that turns this from a technique into a system.

Keep a two-column list. Left column: what you estimated. Right column: what it took. Ten rows is enough to be useful; twenty is enough to be reliable. Divide each actual by each estimate and take the median.

That number is your error ratio, and it is astonishingly stable per person. Most people who have never tracked it land somewhere between 1.4 and 2.2. It does not drift much, because it is not measuring the tasks — it is measuring you: how you scope, what you forget to include, how much of your week actually reaches the work.

Multiply your Step 3 number by your error ratio. If your ratio is 1.6 and the weighted estimate is 11.3 days, you say 18 days.

Two things happen when you do this for a quarter. First, your dates start landing, which changes how people treat everything else you say. Second, your ratio starts falling — not because you got faster, but because the act of recording the gap teaches you what you were leaving out. That is the whole mechanism. A generic "add 50%" buffer teaches you nothing and gets negotiated away in the first meeting. A measured ratio is evidence, and evidence is much harder to argue with.

Step 5: Separate the estimate from the commitment

An estimate is a prediction about work. A commitment is a promise about a calendar. Confusing them is how good estimators still miss dates.

Eighteen days of work does not mean eighteen days from now. Convert with the ratio that matters most and that people forget most reliably: how many hours a day actually reach this project? For most people carrying meetings, support duties and a second project, it is between three and four — not eight. So eighteen days of work is roughly seven or eight weeks on the calendar, before holidays, before the two days you will lose waiting on someone else's approval.

Say both numbers out loud. "About eighteen working days of effort. Given what else is on my plate, that lands around the 6th." The first number defends the work. The second number defends you.

The scripts

When they want one number and you only have a range:

"I can give you a date I'll hit, or a date I'd like to hit. The one I'll hit is the 6th. If you need earlier than that, tell me what to cut and I'll re-estimate against the smaller version — that's a real conversation and I'm happy to have it."

When they push back on the date:

"That number isn't padding, it's history. The last four things this size took 16, 22, 15 and 19 days. I've given you the middle of that. If you want a shorter number I'll need to change the work, not the estimate."

When you're going to be late — and this is the one that matters:

"Heads up: I'm tracking about a week behind on X. The cause is Y. Two options — ship on the original date without the export function, or hold four working days and ship complete. My recommendation is the second, and I need an answer by Thursday to make either work."

Deliver that the day you know, not the week before the deadline. The cost of a slip is not the slip. It is the number of other people's plans that were still built on the old date after you knew it was dead.

Failure modes

• Estimating with an audience. Numbers said out loud in a room with your boss in it are 30–40% shorter than the same numbers written alone. Estimate in private. Present in public.
• Re-estimating the same task after committing. Once you commit, the estimate is frozen; only scope moves. Otherwise you will quietly renegotiate with yourself all the way to the deadline.
• Excluding review, handover and the last 5%. The build is not the job. Approval cycles, documentation and the fiddly final pass are routinely a third of elapsed time and routinely absent from the plan.
• Letting one heroic delivery reset the reference class. The time you did it in nine days was real and it is one data point, probably an unrepeatable one. The median is the median.
• Treating the timebox as an estimate. If you timeboxed three days for research, the deliverable at day three is a decision, not the finished research. Say so when you set it.

When a date does blow up badly enough to hurt, do not just add a buffer next time. Run it properly through the post-mortem process and find out which of the five steps you skipped — in our experience it is almost always Step 2, and the thing that broke was hiding inside a chunk nobody had ever actually built before.

The one-page template

Copy this. It fits on an index card.

• Reference class: last five similar things took ___, ___, ___, ___, ___. Median: ___
• Estimate items: things I've shipped before, each with B / L / W and (B + 4L + W) ÷ 6
• Timeboxes: unknowns, each with a duration and a named decision point
• Sum of items × my error ratio (___) = ___ working days of effort
• Effort hours per day that actually reach this: ___ → calendar date: ___
• Assumptions this date depends on: ___ (write three; these are what you point at when one breaks)
• Actual on delivery: ___ → add the row to the log

The last line is the one that compounds. Everything above it is a technique you can learn in ten minutes. The log is the thing that makes you the person in the building whose dates are trusted, and that reputation is worth more than any individual project you will use it on.