Research on the planning fallacy has repeatedly found that people can underestimate how long their own tasks will take, even when they know similar work took longer before. The practical response is not to stop estimating. It is to use better evidence and smaller units.
Define what “done” means
“Work on presentation” has no clear finish line. “Send the final 10-slide PDF to Maya” does.
Before estimating, complete this sentence:
This task is done when __________.
If you cannot complete the sentence, you may be estimating a project rather than an action.
Include the hidden parts
A task estimate should include more than the central activity. Consider:
- Setup: finding the file, opening the software, gathering information.
- Doing: writing, calling, cleaning, reviewing, or deciding.
- Waiting within the task: downloads, exports, loading, or a short response.
- Checking: proofreading, testing, or confirming the result.
- Closing: sending, filing, cleaning up, or recording what happened.
“Write a short email” may take two minutes once the words are known, but reading the thread, checking a date, finding an attachment, and sending the final version can make it a 10-minute task.
Use the outside view
Instead of asking only, “How fast could I do this?” ask:
- How long did the last three similar tasks take?
- What usually interrupts or delays this kind of work?
- What did I forget to include last time?
- If someone else described this task, what duration would I assign them?
Past examples are imperfect, but they are usually more useful than a fresh best-case story.
Estimate the next action, not the entire fog
Large uncertain projects create large uncertain estimates. Break them at a natural boundary.
| Vague project | Smaller estimate |
|---|---|
| Finish research memo | Read and brief the first two cases — 30 minutes |
| Plan trip | Compare three flight options — 20 minutes |
| Clean apartment | Clear kitchen counters — 10 minutes |
| Fix website | Reproduce the mobile menu bug — 15 minutes |
The smaller estimate does not predict the entire project. It helps you decide what can fit now.
Use ranges when uncertainty is real
An estimate of exactly 23 minutes can imply precision you do not have. A range may be more honest:
- 5–10 minutes for a familiar quick task.
- 20–30 minutes for a defined task with some uncertainty.
- 45–90 minutes for work with research or revision.
For daily planning, broad buckets such as 5, 10, 20, or 30+ minutes may be enough. The goal is to choose and schedule responsibly, not to predict the future to the minute.
Add a buffer for the plan, not the identity
If a task often takes 20 minutes, planning a 25- or 30-minute block is not pessimism. It accounts for ordinary variability. Add more buffer when the task is new, depends on another system, requires careful review, or has a hard deadline.
Do not turn an estimate error into a character judgment. The useful question is: What part of the work did the estimate miss? Update the future estimate with that information.
Separate duration from deadline
Duration answers “How much work might this take?” A deadline answers “When must it be finished?” A planned work time answers “When will I try?”
A 30-minute estimate does not mean the task should be scheduled 30 minutes before its deadline. Leave time for uncertainty, review, interruptions, and recovery.
Example: estimating a presentation
Initial estimate: “Finish slides — 45 minutes.”
Breakdown:
- Find the latest deck and notes — 5 minutes.
- Decide the three-section structure — 10 minutes.
- Draft six remaining slides — 35 minutes.
- Add citations and images — 20 minutes.
- Proofread and export — 15 minutes.
- Send and confirm — 5 minutes.
Revised estimate: about 90 minutes, preferably split across two work sessions with time before the real deadline.
The revised estimate is not a failure. It is a better model of the work.
How FirstNudge uses estimates
FirstNudge can suggest an estimate during assisted Capture, but the estimate remains editable. The Now screen uses the saved estimate to judge whether an action fits the time you selected. If the whole task does not fit, Make Smaller can suggest a shorter starting step.
Unknown duration is not treated as zero, and a short time selection should not hide an urgent longer task.
Time-estimation checklist
- Define the finish line.
- Include setup, checking, and follow-up.
- Look at similar past tasks.
- Break uncertain projects into smaller actions.
- Use ranges or broad buckets when precision is false.
- Add buffer for unfamiliar or deadline-sensitive work.
- Compare the estimate with reality and update the next one.
Frequently asked questions
Should I multiply every estimate by two?
Not automatically. Use past examples and the task’s uncertainty. A familiar five-minute action may need little buffer; a new 90-minute project may need much more.
What if I have never done the task before?
Estimate a discovery step first. Spend 10 or 20 minutes identifying requirements, examples, dependencies, and the likely finish line. Then revise the estimate.
Is a longer estimate less motivating?
It can feel heavier, which is why the next action matters. Keep the honest project estimate, then create a smaller step that fits the time available.