01
Estimate the outcome boundary
Define what “done” means before assigning time. For production work, done often includes reviewed code, a working build, an environment release, functional QA and a public verification.
The estimate should stop where responsibility stops. If another team owns final production deployment, say so.
02
Keep work categories visible
Separate implementation, review, QA, deployment and technical coordination. This shows where process overhead dominates a very small task and helps decide whether the normal engineering path is appropriate.
Do not enlarge the coding estimate to make the total feel acceptable.
03
Price uncertainty honestly
Confidence depends on reproduction, source access, environment parity and how many systems are involved. A range should cover known uncertainty, while a low-confidence scope should name the investigation path and the point where work stops for re-estimation.
A label is not enough. State what evidence would tighten the range.
04
Leave room for normal drift
Small clarifications often appear during handoff or QA. A delivery estimate can include a modest contingency without turning into an unbounded budget.
When a change fits the contingency, update the scope and proceed. When it changes the system or failure mode, return to the decision-maker.