How to estimate tasks

Buehler, Griffin and Ross ran the definitive studies on this in 1994. People underestimate how long their own tasks will take, and they do it even when they know they have underestimated similar tasks before. The detail that makes the finding useful is what happens when someone else predicts your completion time: the bias mostly disappears. Observers, working from the same information, are not systematically optimistic about your schedule.

That tells you the problem is not ignorance. You have the data. When you plan your own work, you build the estimate out of a specific imagined path where nothing goes wrong, and you leave your track record out of it. Someone watching you has no imagined path, only your history, so they estimate from the history.

The immediate practical move follows from that: for anything that matters, ask a colleague who has seen you work to guess. It costs a minute and it routinely returns a number 30 to 50 percent higher than yours. If nobody is available, the rest of this page is about how to imitate the outsider's view on your own.

This is the countermeasure with the strongest track record, developed by Kahneman and Lovallo and applied at scale to infrastructure projects by Bent Flyvbjerg. The rule is blunt: do not estimate the task in front of you. Find the class of similar things you have already finished, look up what they actually took, and use that distribution.

In practice, for a piece of personal or engineering work, that means opening your records rather than your imagination. Find the last three comparable items. Write down what each one really took, from start to genuinely done, including the review round and the bug that came back two days later. Take the median. If this task feels different, note in one sentence exactly why, and be suspicious of yourself, because every task feels different from the inside.

The obvious objection is that you do not have records. That is usually true at the start and stops being true after a few weeks of noting actuals. Storing the estimate next to the task is the whole trick. The task manager keeps a focus-session estimate per task, which after a month gives you a personal reference class rather than a vague sense that things run long.

Kruger and Evans (2004) showed that breaking a task into its components raises estimates toward reality. When people price a job as a single thing, they price the part they are picturing. When they list the parts, the forgotten ones appear and the total goes up.

The useful discipline is to list every step you would have to complete before you could honestly call the task done, then estimate each step separately and add them. For a piece of writing that might be the outline, the draft, the fact checking, the edit and the formatting. For a code change it usually includes tests, the review round trip, the deployment and the follow-up. The steps people leave out are almost always the ones after the interesting part is finished.

One caution: unpacking helps most for tasks you are underestimating, and it can slightly inflate estimates for very simple work by making trivial steps feel substantial. Unpack anything longer than half a day. For a 20-minute errand, skip it.

Buehler's own successful intervention was more specific than "think about history." People asked to recall a similar past task, and then explicitly connect that memory to the current plan, produced less optimistic and more accurate estimates. Simply being told about the planning fallacy did nothing. Merely recalling the past without linking it to the plan did not help much either.

So write the link out in a sentence. "The last API integration I said would take two days took five, mostly because the sandbox credentials took a day to arrive. This one has the same dependency, so five days." That sentence is the intervention. It is doing something a mental note does not do, because it forces the specific mechanism of the previous overrun into the current number.

Estimate the failure modes, not the happy path

A related habit that costs almost nothing: before finalizing a number, ask what would have to go wrong for this to take twice as long, and how likely each of those things is. You are not trying to build a probabilistic model. You are trying to interrupt the single smooth story your planning brain has already written.

A large share of estimation error is not about the work at all. It is that eight hours at a desk are not eight hours of work. Meetings, messages, context reloading and the genuine ceiling on concentrated effort mean a good day contains something like three to four hours of real focused output. Ericsson's work on deliberate practice found that even people whose full-time job is focused effort rarely sustain more than about four hours of it daily.

So estimate the task in focus sessions of a fixed size, then convert to calendar time using your actual daily capacity rather than your working hours. Six sessions of 45 minutes is roughly two days for most people, not half a day. This one change fixes a surprising fraction of chronic lateness, because the task estimate was often fine and the schedule around it was fantasy. The work hours calculator is useful for the second half of that sum, and how many focus hours you can realistically do goes into the capacity number in detail.

Ariely and Wertenbroch (2002) gave students either evenly spaced deadlines, a single final deadline, or the freedom to set their own. Self-imposed deadlines did help, students used them, and they reduced procrastination compared with having only the final date. But they did not perform as well as externally imposed, evenly spaced deadlines. People do not space their own deadlines optimally, and the ones they set carry less weight than the ones someone else is expecting.

The practical version is to attach a person to the date. Tell a colleague when to expect the draft. Book the review meeting before the work is finished. An estimate that nobody else knows about is a private opinion, and private opinions slide.

Give a range rather than a point when you communicate the number, and make the range honest rather than a padded single figure. "Three to five days, five if the credentials are slow" tells the other person something actionable. "A week" with two days of hidden buffer teaches them to discount everything you say.

Estimation improves through calibration, and calibration needs recorded actuals. Recording the estimate is easy and everybody does it. Recording what it really took is the part that gets skipped, which is why so many people have been estimating for a decade without getting better at it.

Keep it lightweight. When a task closes, write the actual next to the estimate and one short note about the reason for any gap. Once a week, look at the ratio across everything you closed. Most people find a stable personal multiplier somewhere between 1.3 and 2.0, and simply multiplying by it beats every clever technique on this page. The multiplier is not a moral failing; it is a measurement, and it is the closest thing to a free improvement in this whole area.

The weekly review is a natural place to check the ratio, and the Get It Done review wizard walks through it. Track the number for a month before you conclude anything; a single badly missed estimate tells you about that task, not about you.