Most engineers are not bad at estimation because they are careless. They are bad at it because they treat estimation like prediction instead of risk communication.
The point of an estimate is not to sound certain. The point is to make uncertainty visible early enough that the team can plan around it.
Break the work into parts before you estimate
If you estimate a task as one big block, you usually miss the hidden work around it.
Before giving a number, list the likely buckets:
- code changes
- tests
- migrations or data changes
- integration work
- deployment or rollout steps
- unknowns that require investigation
This is often enough to expose where your confidence is real and where it is fake.
Separate known work from unknown work
A common mistake is to average everything into one number. That hides the actual risk.
A better framing:
- “The code change itself looks like half a day.”
- “I still need to validate how this integrates with billing.”
- “If that part is straightforward, I think the total is 1-2 days.”
That sounds more competent because it shows reasoning instead of bluffing.
Use ranges with assumptions
Ranges are useful when they are tied to conditions.
Good:
- “1 day if the schema stays unchanged, 2-3 days if we need a migration.”
Bad:
- “Maybe 1-3 days, hard to say.”
The first version tells people what could change the estimate. The second version just signals uncertainty without structure.
Call out the first thing that could break the estimate
The strongest estimation habit is not the initial number. It is the early update.
If you discover new information, say it quickly:
- the dependency behaves differently than expected
- rollout is riskier than the code change
- test coverage is thinner than assumed
- a requirement is still ambiguous
This is where better questioning helps. If scope is fuzzy, fix that by asking sharper questions earlier. See How to Ask Better Technical Questions at Work.
Use checkpoints for larger work
For anything bigger than a small ticket, estimate the next checkpoint, not just the whole task.
Example:
- by today: confirm the approach
- by tomorrow: finish implementation
- after that: test and ship
This makes progress easier to track and makes it easier to update the estimate without creating drama.
Avoid the two worst estimation behaviors
The first is fake confidence:
- giving the smallest optimistic number
- hoping you can make it true later
The second is defensive vagueness:
- refusing to estimate at all
- hiding behind “it depends” without explaining what depends on what
Strong engineers do neither. They give the best current range, name the assumptions, and update early.
A simple estimation pattern
Use this sentence structure:
- “I think this is about X to Y.”
- “That assumes A, B, and C.”
- “The main risk is R.”
- “I should know more after checkpoint.”
That is enough for most planning conversations.
If you want to build the bigger pattern that leads to stronger ownership, pair this with How Mid-Level Engineers Start Acting Like Senior Engineers.