How to estimate task duration: methods and examples

Why do task estimates come out too short?

People often picture the current task going to plan and give too little weight to previous delays. Asking for an estimate and checking it against past results tackles that bias from two directions.

The clearest small-scale example is a 1994 study of honours thesis students by Roger Buehler, Dale Griffin and Michael Ross, published in the Journal of Personality and Social Psychology. Thirty-seven final-year psychology students were asked when they would hand in their thesis. Their best guesses averaged 33.9 days; they actually took 55.5. Fewer than a third finished by their own best estimate. The next part is the one to remember: the students were also asked for a date "if everything went as poorly as it possibly could", and fewer than half finished even by that.

The same paper found that people's predictions were too optimistic for a range of tasks, and that the bias disappeared in one study where participants were explicitly told to connect relevant past experiences with their prediction. That is the practical lesson for anyone building a schedule. A better estimate usually comes from evidence outside the task, how long the same kind of work took before, rather than from thinking harder about the task itself.

Bent Flyvbjerg's paper on the outside view explains reference class forecasting: start from outcomes of comparable projects, rather than only the details of the new plan. Small teams can apply the same principle by recording comparable tasks and their actual durations.

Which estimating method fits which task?

Use the cheapest method that gives you a believable number. Most tasks in a typical plan need one quick question, a handful need a breakdown, and only a few deserve the full three-point treatment.

Most tasks get more than one of these. The designer gives an estimate, you compare it with the last brochure she did, and the two numbers together are more reliable than either alone.

Who should give the estimate?

Start with the person doing the work. They know the steps, assumptions and likely interruptions. Treat their estimate as an input to check, not a promise to extract.

Ask for a range and its assumptions. "Three to five days if the copy is approved" tells you more than "four". Then check how much time the person can actually give the task: an estimate assuming uninterrupted work will not fit someone already split across three projects.

Where the work sits with someone outside the team, a supplier, another department or a client, ask them too, and add one extra question: how long did it take the last few times? A furniture supplier who quotes ten working days and has delivered in thirteen twice running is telling you two different things, and the second one is the estimate.

How do you estimate work you have done before?

Find a few genuinely similar past tasks, look at how long they actually took, and start from there rather than from a fresh guess. It is the small-team version of what Flyvbjerg's paper calls reference class forecasting: pick a relevant group of comparable past projects, look at the spread of their results, and place the new project within that spread.

For a small team, even a few comparable tasks are a useful starting point. If the last newsletters took 3, 4 and 6 days, four is the median and six is a recent slower outcome. Check what caused the spread before choosing a duration. A new format or longer review chain may need a different comparison.

Two things spoil this method. The first is memory: people recall the run that went smoothly and quietly forget the one held up by a sick day. The second is choosing comparisons that flatter. A twelve-page brochure is not a reference for a forty-page catalogue. If you do not have real numbers for past work, this method is guessing with extra steps, which is the case for recording them from now on (more on that below).

What if a task is too big to estimate?

Break vague work into activities with clear outputs. "Build the website" may contain copy, design, development and review. Estimate those pieces, then work out their sequence; summing their durations only gives the elapsed total when they all run one after another.

Choose pieces small enough to estimate and check at your review cadence. For a small project, a day to two weeks is often useful; it is not a universal limit. Keep finer detail in a checklist unless it has a separate owner, deadline or dependency.

If the project as a whole needs this treatment, starting from the scope rather than the schedule helps. The guide on turning a work breakdown into a schedule covers how far to decompose and how the levels become phases and tasks.

When is a three-point estimate worth the effort?

Use three-point estimates when a task's uncertainty could materially change the schedule, including tasks outside today's critical path. A short branch can become critical if a delay consumes its float. The GAO schedule guide recommends monitoring near-critical paths as well as critical ones.

Good candidates include first-time work, uncertain approvals and suppliers with a wide delivery range. Estimate optimistic (O), most likely (M) and pessimistic (P) durations. PERT uses (O + 4M + P) / 6, which weights M most heavily. The PERT example shows the calculation.

One warning from the thesis study above. The students' worst-case dates were still too early for more than half of them. A pessimistic estimate is not automatically a safe one. When you ask for the bad case, ask for the realistic bad case, the one that happened last time, not the one that feels pessimistic enough to say out loud.

Effort or duration: which number goes on the bar?

Duration is the time from planned start to finish under the task's calendar. Effort is the amount of work. Six person-days of effort might take six working days at full availability, twelve at half availability, or longer if there are reviews and waiting periods.

For the example below, the designer needs six days of effort and can give the project half of each working day. That suggests twelve working days of duration, assuming no extra waits. Check that the half-time availability is real before putting the number on the chart.

The fix is simply to ask both questions: how much work is it, and how much of your week can it have? Then put the calendar answer on the chart. In Ganttile you can switch on the Estimate column in the grid to keep the effort figure next to the task, so the bar can show the duration without the work estimate getting lost.

Weekends need the same care. A task of ten working days that starts on a Thursday finishes on the Wednesday after next, two weekends later. Ganttile counts calendar days unless Hide weekends is turned on, so check that setting before you trust an end date.

Where should the buffer go?

For a small project, a visible buffer before an important milestone is often easier to monitor than contingency hidden in every task. Choose an allowance based on risks and review it as the plan changes.

Hidden padding makes it hard to distinguish work estimates from safety allowances. It can also be lost when early finishes do not bring later work forward. Explicit task-level contingency can be managed too; the important thing is to know what the allowance covers and avoid counting it twice.

A shared buffer gives the team one visible allowance to track. In a simple Ganttile plan, the chart keeper must reduce that buffer as overruns consume it. With Auto schedule turned on, linked tasks move, but the chart does not decide how much contingency to use.

Check every path feeding the milestone. A noncritical task may have less float than its plausible overrun, so it can still consume contingency or take over the critical path. For a small plan, discuss the likely combinations of delay and document the allowance you choose.

A worked example: trade show materials in six weeks

A small company has 31 working days, about six weeks, until its materials need to be at the venue for a trade show. The day counts below are working days, which in Ganttile assumes Hide weekends is turned on. Here is how each task's estimate was reached and what went on the chart.

• Write the brochure copy, 5 days: compared with past work. The last two brochures took 4 and 6 days from brief to final copy.
• Design the brochure, 12 days: asked the designer. She estimated 6 days of work, and she is on this project half time, so the bar is 12 working days.
• Legal review of product claims, 6 days: three-point estimate, because nobody knows how picky the review will be: 2 days at best, 5 most likely, 14 if claims need rewording.
• Print the brochures, 7 days: supplier quote, checked against the last order, which arrived on time.
• Booth banner and demo setup, 10 days: broken down because the team has never done it: 2 days to design the banner, 5 for the supplier to make it, 3 to put the demo kit together and test it.
• Ship to the venue, 3 days: courier's standard service.

Design and legal review both start once the copy is done, and printing waits for both. The booth work runs on its own from day one. The chain that decides the date is copy, design, print and shipping: 5 + 12 + 7 + 3 = 27 days. Legal review has six days of float alongside design, and the booth has plenty.

Legal review shows why checking only the current critical path is risky. Its expected duration is six days, but the pessimistic estimate is fourteen. If that happens, it outlasts the twelve-day design task by two days and becomes the gate for printing.

The team reserves the remaining four days as a visible buffer before "Materials at venue". If design overruns by three days, the chart keeper reduces the buffer from four days to one and checks that the arrival target still holds. If the delay exceeds four days, show the later forecast and discuss faster shipping, a smaller print run or another recovery option.

Compare an equal amount of hidden padding: copy 6 days, design 13, print 8 and shipping 4. That totals 31 days, exactly the same as 27 days of work plus a four-day buffer. The visible version is not shorter; its advantage is that everyone can see and discuss the remaining allowance.

How do you know if your estimates were any good?

Compare planned and actual duration after each task or project. Record why they differed: effort, availability, waiting, changed scope or an inaccurate estimate. That distinction matters more than simply labelling the estimate wrong.

The comparison needs two numbers per task: the planned duration, and how long the work really took. The first is easy to lose, because a good chart changes as the project moves and the original plan disappears under the updates. Before work starts, export the chart to Excel or PDF and keep the copy, since that is the plan you are going to check against. The guide on tracking delays covers comparing plan and actual while the project is still running.

Record actual start and finish dates as well as effort where useful; logging time by project gives you the effort figure. Time logs explain work hours; they do not capture all the waiting that determines duration. A review held in someone's inbox for a week needs a different correction from a design task that took twice the effort.

Look for patterns across comparable work. If design repeatedly takes longer, check whether scope, availability or review rounds explain it before applying a blanket multiplier. Keep supplier and internal-review delays separate so the next estimate reflects the cause.

Before you commit to the dates

Should task estimates be in hours or days?

Use units that match the work and the chart. Days are practical for the multiweek examples here; hours can suit short activities in tools that support them. Keep effort hours separate from elapsed duration and avoid rounding every small task upward before adding them together.

What do you say when someone wants a single date?

Give the date that includes the buffer, and say what it depends on. "The 14th, provided legal reply within a week" is still a single date, and it tells people which risk to watch.

How often should estimates be revised?

Whenever a task finishes or real news arrives, rather than on a fixed timer. Re-estimating the tasks that have not started yet, using what the finished ones taught you, is what keeps the end date believable.

Build an estimate you can explain

For each task, record the duration, the evidence behind it and the assumptions it depends on. Check uncertain branches as well as the critical path, and keep the original plan for comparison.