The error is systematic — and that is the good news
Almost everyone knows the feeling: a task budgeted at one hour takes two. The usual reaction is self-blame — should have concentrated harder, allowed fewer interruptions, prepared better.
That is the wrong diagnosis. The error is not randomly distributed: estimates come out too low almost every time and practically never too high. An error that always points the same way is not a slip, it is a bias — and bias can be calculated out.
The effect has a name: the planning fallacy, described in the 1970s by Daniel Kahneman and Amos Tversky. The core of it: when we estimate, we imagine the intended run of the task — how it would go if it went smoothly. What actually interferes (a question back, a broken test run, a colleague in the doorway) is not in the picture, because you cannot picture it individually. And because interruptions are individually unpredictable but collectively very regular, the estimate is reproducibly short.
Disclosure: we build Balane Plan, an app that derives this factor automatically from measured work sessions. The method in this article works just as well in a spreadsheet.
Why experience alone does not fix it
You might assume the problem disappears with routine. It does not — and the reason is interesting: experience improves your picture of the sequence, not your accounting for the interference.
Someone writing their fiftieth quote knows exactly how the writing goes. What they still do not include when estimating: that in two out of five cases a clarification is needed, that the price list may be out of date, that the client will add a variant. Each of those events is unlikely on its own; that one of them happens is the norm.
So the only thing that helps is the outside view: not imagining better, but looking up what comparable tasks actually took. In the research this is called reference class forecasting — estimating from comparable cases rather than from the case in front of you.
Step 1: measure for two weeks and change nothing
The first step is unspectacular and the only one that really matters: measure without adjusting your behaviour.
What you need:
- For every task you start: the estimated duration (written down beforehand), the actual duration, and the kind of work.
- A split between working time and waiting time. Two hours spent waiting for an answer is not work on the task. Mixing them produces factors of 4, which are useless.
- The honesty to fill in what you forgot. People forget to start the timer. If you drop those sessions you are only measuring the tasks you were calm enough to time — disproportionately the quiet ones. The sample skews and the factor comes out too low.
Two weeks is enough for a first number. Ten to fifteen completed tasks per kind of work is a workable basis.
Step 2: split by kind of work, not by project
The most common analysis mistake is producing a single factor for everything. That averages together kinds of work that behave completely differently.
A sensible split is by kind of work:
| Kind of work | Typical factor | Why |
|---|---|---|
| Concentrated solo work (writing, calculating) | 1.1–1.3 | Little outside interference, the sequence is easy to picture |
| Building something new | 1.4–1.8 | Unknowns only appear while building |
| Debugging | 1.8–3.0 | The duration depends on a cause you by definition do not know yet |
| Coordination | 1.6–2.2 | Other people's response times and calendars |
| Recurring routine | 1.0–1.2 | The sequence is known and the interruptions are familiar |
These numbers are experience, not physical constants. They serve as a starting value until you have your own. Your own are the only ones that count.
The debugging row deserves particular attention: it is the one kind of work where estimation in the strict sense is impossible, because the duration hangs on an unknown cause. For it you do not plan a duration, you plan a timebox — "search for 90 minutes, then decide again".
Step 3: calculate the factor
The calculation is one division:
correction factor = sum of actual durations
÷ sum of estimated durationsDeliberately take the sums, not the average of the individual factors. Otherwise a 10-minute task that took 30 minutes (factor 3) counts as much as a full-day task that was 10% off. For planning purposes you care about time, not about the number of cases.
An example for the kind of work "building":
| Task | Estimated | Actual |
|---|---|---|
| Import module | 90 min | 155 min |
| UI error message | 30 min | 40 min |
| Export format | 120 min | 145 min |
| Test coverage | 60 min | 110 min |
| Total | 300 min | 450 min |
450 ÷ 300 = 1.5. From now on you estimate exactly as before — and multiply by 1.5 before the number goes into the plan.
That is the whole trick. You do not have to learn to estimate better. You only have to calculate your known error once and then apply it.
Step 4: three traps in applying it
Trap 1: baking the factor into the estimate. If you start saying "90 minutes" while meaning 60 minutes of work plus buffer, you can never again check whether the factor is right. Estimate the pure work and multiply separately. That is the only way the measurement stays analysable.
Trap 2: reading the factor as an accusation. A factor of 1.6 does not mean you work 60% too slowly. It means 60% of your real working time consists of things you do not see when you picture the task — and that turn up every single time anyway. The factor is a property of the work, not of the worker.
Trap 3: never revisiting it. It moves: with the project, the team, the familiarity. Check it every two or three months.
What happens to long tasks
For anything longer than half a day, multiplication breaks down because the spread gets too wide. The only thing that helps here is decomposition.
A task estimated at "one to two days" is not an estimate, it is an admission that the task is not yet understood. Break it down until each part fits into a focus block (25 to 120 minutes). Two things happen:
- 1.Decomposition surfaces what is still unclear — and that is exactly the part that eats the time later.
- 2.The sum of the parts regularly comes out above the original whole-task estimate. That is not a flaw in the decomposition. That is the amount the whole-task estimate was hiding.
Why somebody else's estimate rarely helps
A common reflex in teams: "how long will that take you?" The answer suffers from two biases — the planning fallacy, plus the social pressure not to say an uncomfortable number.
More robust is asking for the reference class: "how long did something like this take you last time?" It moves the view from imagination to memory, and it reliably produces a more honest number — provided there are measurements to remember.
That is the point at which tooling starts to earn its place. Balane Plan records work sessions server-side — including the reason for each pause, so that waiting and working stay apart — and derives the factor per person and per kind of work. The estimate for the next task is then model estimate × your factor × complexity, and that number feeds straight into day planning without anybody having to hold it in their head.
What you get out of it after four weeks
- Plannable days. The difference between a day that is 40% overcommitted and one that works out is exactly this one multiplication.
- Negotiable deadlines. "Historically this takes 1.6 times the pure working time" is an argument. "I think that will be tight" is not.
- Less self-blame. Once you know the error was in the method and not in your concentration, you stop reaching for the wrong lever.
The method costs two weeks of attention and then one multiplication. That is an unusually good ratio for one of the few places in time management where you can actually do the arithmetic.
Common questions
How many measurements do I need for a usable correction factor?
Ten to fifteen completed tasks per kind of work is enough for a first usable number. What matters more than the count is that the sample is not skewed — if you only measure the tasks you remembered to time, you are measuring your quiet days.
Why does experience alone not cure low estimates?
Because the error does not come from missing knowledge. When we estimate, we picture the intended sequence of steps, not the interruptions. Experience improves the picture of the sequence; it does not add the things that get in the way.
Should the buffer go inside the estimate or be kept separate?
Separate. An estimate with the buffer baked in can never be checked against the measurement, because you never learn whether the buffer was needed. Estimate the pure work, multiply by your factor, and plan the daily buffer on its own.
What is a typical correction factor?
For most people it lands between 1.3 and 1.8. Concentrated solo work sits at the low end; anything involving coordination, questions or other people's input at the high end. There is no universal value — yours is the only number that counts for you.