Before Estimating a Task, Look at What Comparable Tasks Actually Took
Estimate work using comparable completed tasks, separate effort from elapsed time and explain uncertainty ranges with a transparent planning worksheet.
The task looks like five hours of work. You tell a colleague it will be ready tomorrow, then discover that the source export arrives late and the reviewer has no free slot. Five hours was a plausible effort estimate. Tomorrow was a different claim about a calendar.
A useful estimate connects the task to comparable completed work and shows how effort becomes elapsed time. It also states what the range includes. A wide range without assumptions can be as unhelpful as a precise date that nobody can defend.
This evergreen guide offers an original worksheet for ordinary workplace tasks. It draws on planning research and estimation guidance without pretending that a five-row office example is a calibrated statistical forecasting model.
Define what counts as finished
Before selecting comparisons, describe the result. “Prepare the report” may mean an internal draft, a checked analysis or a release approved by a customer. Those endpoints require different work and different waits.
Write the acceptance condition, the included revision allowance and the starting condition. In our example, a task starts when usable source data is available and ends when one reviewer accepts the report. External publication is excluded.
If previous tasks ended at draft submission while the new task ends at approval, their elapsed times are not directly comparable. Correct the endpoint or explain the difference before calculating a summary.
Choose a reference class before seeing a convenient answer
A reference class is a set of completed tasks similar enough to inform the new estimate. Choose characteristics relevant to duration: artifact type, data condition, review path and team capacity. Avoid choosing only the fastest examples after deciding what deadline you want.
Include ordinary delays that belong to the workflow. If reviewer queues occur repeatedly, calling every queue an exceptional event removes a recurring part of the task from the evidence.
Record exclusions and reasons. A genuinely different emergency project may not belong in the comparison, but an inconvenient long task should not disappear merely because its duration makes the estimate less attractive.
Keep effort and elapsed time in separate columns
Consider five invented reporting tasks with the same start and finish definitions. Active hours include preparation and revisions. Elapsed business days include waiting and the effect of other work competing for attention.
| Completed task | Active effort | Elapsed business days | Relevant context |
|---|---|---|---|
| A | 4 hours | 2 | Clean data; reviewer available |
| B | 5 hours | 3 | Routine review queue |
| C | 6 hours | 3 | One clarification |
| D | 5 hours | 4 | Competing work |
| E | 7 hours | 6 | Data repair and review delay |
Sorted effort is 4, 5, 5, 6 and 7 hours, so its median is 5. Sorted elapsed time is 2, 3, 3, 4 and 6 days, so its median is 3. Neither median turns five hours into one business day.
Use past experience to challenge the plan
Buehler, Griffin and Ross's 1994 research examined optimistic completion predictions across several tasks. Participants often focused on the future plan; one study reduced optimistic bias by instructing participants to connect relevant past experience with their prediction.
That finding supports inspecting the connection between a new plan and earlier outcomes. It does not establish that a fixed percentage buffer will correct every estimate, or that a colleague who misses a date has the same psychological cause.
Ask which specific conditions make this task different. “This time will be smoother” needs evidence, such as source data already validated or review capacity actually reserved.
Build scenarios with explicit arithmetic
The new report is larger than the previous examples. Suppose the owner can protect two active hours per business day. For illustration, assume work and the final review wait occur sequentially, with no overlap or weekend complications.
| Conditional scenario | Active effort | Effort at 2 hours per day | Final review wait | Elapsed total |
|---|---|---|---|---|
| Cleaner input | 6 hours | 3 days | 2 days | 5 days |
| Working assumption | 8 hours | 4 days | 2 days | 6 days |
| Repair and slower review | 10 hours | 5 days | 4 days | 9 days |
These totals are conditional calculations, not percentiles. “Five to nine business days under these scenarios” describes their meaning. Calling the same range an “80% confidence interval” would require evidence and a statistical method that this worksheet does not provide.
Explain adjustments instead of hiding padding
NASA's Cost Estimating Handbook, Appendix C, describes analogy-based estimating using historical information and documented adjustments for relevant differences. Its setting is project cost estimation, so the office worksheet here is an adaptation of that reasoning principle.
Document the new task's larger scope, assumed daily capacity and review arrangement. Someone reading the estimate should be able to challenge an input without reconstructing your entire thought process.
Do not apply a scope adjustment and then quietly add another allowance for the same expected revisions. If contingency covers a separate risk, name it separately so you can see what has already been counted.
Keep a range distinct from a commitment
An estimate describes an expected outcome under stated information and assumptions. A commitment adds a decision about what the team will do to meet a date. Confusing them can turn an uncertain forecast into an apparent promise without changing any resource constraint.
If a stakeholder needs delivery in four business days, show the gap. Under the working scenario, preparation takes four days before the two-day review wait. A shorter commitment needs a changed arrangement, such as reduced scope, additional effective capacity or earlier review participation.
Check whether those changes actually remove the limiting step. Adding another contributor does not automatically reduce a reviewer queue.
State uncertainty without inventing precision
The observed range of two to six days in five historical tasks is a description of that small sample. It does not bound all future outcomes. New tasks can exceed it, especially when scope or conditions change.
NASA's Appendix G on risk and uncertainty emphasizes that a single estimate can hide overrun exposure and that uncertainty assessments need support. The lesson used here is to show assumptions and consequences; no NASA policy threshold is being applied to office work.
Avoid adding separate “high” estimates and calling the sum a particular percentile. Dependencies and the meaning of each range matter. More decimal places cannot repair missing evidence.
Update the estimate at a useful checkpoint
Set a review point where information is likely to improve: after inspecting the source data or confirming reviewer availability. Record the previous estimate and explain what changed. Quietly overwriting it loses the evidence needed to learn whether the process is improving.
For the completed task, preserve actual active hours, elapsed time, scope changes and waiting causes. Over several comparable tasks, examine whether ranges consistently miss in the same direction before changing the method.
For coordinating the next owner, see workplace handoff acceptance. An estimate becomes easier to use when the person responsible for the next action and the definition of completion are equally clear.
Sources and limits
- Buehler, Griffin and Ross, 1994: primary research on completion-time predictions and planning bias.
- NASA CEH Appendix C, February 2015: estimation methodologies and analogy adjustments.
- NASA CEH Appendix G, February 2015: risk and uncertainty in cost estimation.
Checked October 25, 2026. Historical tasks, capacity assumptions and scenarios are fictional. This planning worksheet is not a validated forecasting model, contractual delivery guarantee or application of current NASA project requirements.