Estimating work: why "about three days" becomes three weeks

Bad estimates are rarely just optimism. They are a mismatch of scope: you priced typing time, your listener heard delivery time.

The parts that go missing

A feature consumes more than coding:

Step	Why it gets underestimated
Reading the existing code	“I know this codebase” is an assumption
Integration	the other side’s API is not ready
Rework after review	review comments are not predictable
Testing and fixing	only the happy path was priced
Deploy and verify	one environment issue eats half a day

Quoting only coding days silently declares all the rest to be zero.

Give a range, not a number

“Three days” carries no information. Give a range with its basis:

2 to 5 days.
2 days: the API is ready and existing code can be reused.
5 days: a new table is needed and another team must integrate.

A range is not vagueness; it is stating the uncertainty out loud. A single number means either gambling or never having considered risk.

Split until pieces fit in half a day

A task over two days cannot be estimated because it hides too many unknowns. Break it into sub-items under half a day and the error drops sharply — not because you got better, but because each step has fewer unknowns.

x build user export (5 days)
v add export endpoint (1 day)
  add download button (0.5 day)
  stream large files (1 day, uncertain)
  permission checks (0.5 day)

The one marked uncertain is exactly what deserves its own conversation.

Calibrate against history

Feelings are unreliable. Record actual durations and compare next time:

estimated 2 days -> took 4
estimated 1 day  -> took 1.5
average factor ~ 2

After a dozen records you will find a stable multiplier of your own. Accept it and apply it, which beats promising to be accurate this time.

What should not be estimated

• Features with an unsettled spec: estimate how long clarifying takes first
• Parts waiting on another team’s schedule: that is waiting, not work
• Tech you have never used: schedule a spike instead

The third matters most: never promise something you have not done, only promise how long until you know whether it can be done.

Estimation is not a skill problem, it is an information problem. Split the unknowns, state the range, calibrate on history, and let time handle the rest.