The single most reliable way to damage trust with a product team is to give an estimate and then miss it by a factor of three. Not because you were lazy. Because you estimated optimistically and did not account for what you did not know.
Estimation is uncomfortable because it requires admitting uncertainty. Most engineers avoid the discomfort by being optimistic instead. The team takes that optimism as a commitment. The gap between commitment and reality is where trust breaks.
Estimate ranges, not points
A point estimate is "I think this will take three days." A range estimate is "I think this will take between three and seven days, with three being the case if nothing unexpected comes up."
The range communicates the uncertainty that is always present in software estimates. It is also more honest. When you say three days, you are guessing. The range makes the guess visible.
The three questions before estimating
- What do I know about this task? The parts you understand well are the fast parts.
- What do I not know? Integration with an unfamiliar API, a codebase area you have not touched, a database migration with unknown data quality — these are where estimates go wrong.
- What could go wrong? Not catastrophically, just normally. A dependency upgrade that breaks something, a schema that needs adjustment, a review cycle that requires two rounds.
The answer to question one is what most engineers estimate. The answers to questions two and three are what the actual time gets spent on.
Spike before estimating the unknown
If the estimate requires knowing how an unfamiliar system works, do a short investigation first. A two-hour spike on an unfamiliar API or codebase area turns a three-day unknown into a three-day known.
Estimating before the spike produces a number with no information behind it. Estimating after the spike produces a number with actual understanding behind it.
When your estimate changes mid-task
Communicate early, not after the deadline passes. If you are two days into a three-day task and you have found something that will take two more days, the right time to say so is now — not when the deadline arrives.
Early communication gives the team options: adjust scope, extend the timeline, bring in help. A deadline surprise gives the team no options.
The goal is not accuracy
The goal of estimation is shared understanding, not prediction. An estimate that communicates what you know, what you do not know, and what could go wrong — even if the number turns out to be wrong — is more valuable than a precise number that nobody questioned.