What you'll learn
Quick Answer
Estimates are wrong because you estimate the code you imagine writing, not the integration, review, testing and unexpected problems around it. Break work down, estimate ranges rather than points, and track your own error factor.
Why the error is systematic
Underestimation is not carelessness. It has specific causes, and they are the same for everyone.
You estimate the happy path. Asked how long a feature takes, you picture writing the main code. You do not picture the API returning an undocumented shape, the migration failing on staging, or review feedback requiring a rework.
The unknown parts are invisible. You cannot estimate a problem you have not discovered yet, and complex work always contains some.
Everything except coding is forgotten. Writing tests, code review and its rounds, deployment, documentation, and the meeting about it. On many tasks the code is under half the total time.
Interruptions are excluded. You estimate focused hours and then have three meetings and a production issue.
Because the causes are systematic, the error is systematic — which is exactly what makes it correctable.
Break it down until the pieces are boring
The single most effective technique.
"Build the booking feature" is unestimable. Broken down:
- Database schema and migration — 2 hours
- Availability check with locking — 4 hours (the genuinely hard part)
- API endpoints — 3 hours
- Frontend form and validation — 4 hours
- Tests including the concurrency case — 3 hours
- Review and rework — 2 hours
Two things happen. The total is more realistic, because you counted things you would have forgotten. And the breakdown itself reveals the uncertainty — you can see which item you are least sure about, and that is where the risk is.
If a piece is bigger than about a day, break it further. Anything you cannot break down is something you do not understand well enough to estimate, which is itself worth reporting.
Give ranges, not points
"Three days" implies a precision you do not have, and it will be recorded as a commitment.
"Two to five days, most likely three" communicates the actual state of your knowledge. A wide range is information — it says the work is uncertain — and it invites the useful question: what would narrow it?
Often the answer is a spike: a timeboxed investigation to remove the biggest unknown. "Give me half a day to check whether their API supports this, then I can estimate properly" is a professional response, not an evasion.
State your assumptions alongside the number. "Three days, assuming the design is final and the staging environment works." When an assumption turns out false, the estimate changing is expected rather than a failure.
And update the estimate when you learn something. An estimate is a forecast, not a promise. Saying on day two that it will now take five days is far better than saying nothing until day three.
Learn your own multiplier
The most practical improvement available, and almost nobody does it.
For two weeks, write down your estimate before starting each task and the actual time afterwards. Then compare.
Most people find a fairly consistent ratio — commonly somewhere between 1.5 and 3 times their estimate. Once you know yours, you do not need to estimate better. You estimate as usual and multiply.
This works because the bias is stable. It also removes the moral weight from the problem: you are not bad at your job, you have a measurable systematic offset, like a scale that reads light.
The related technique is reference-class estimation — instead of reasoning from scratch, ask how long the last similar thing took. Past actuals are far better predictors than fresh reasoning, because they already include everything you forget to count.
Communicating estimates well
- Never give a number under pressure in a meeting. "Let me break it down and come back this afternoon" is a complete answer. Numbers given on the spot become commitments.
- Separate estimate from deadline. If a business date is fixed, the conversation should be about scope, not about whether you can work faster.
- Flag slippage early. The cost of a delay is mostly in the surprise. Two days' notice lets people plan; discovering it on the due date does not.
- Do not pad silently. Doubling privately and reporting the doubled figure erodes trust when discovered. State the range and the assumptions instead.
- Include review and testing explicitly so they are visible rather than absorbed into a number that looks too small.
For students, this matters most on final year projects, where the deadline is fixed and the estimate is entirely yours. See time management for coding students and scoping a project you can finish.