Estimation & Scoping

Estimates are forecasts, not commitments, and most of the pain around them comes from the two sides quietly using different definitions.

Decompose until the pieces are familiar. "Build the reporting feature" is unestimable. Break it down until each piece resembles something you have done, then add up. Anything you cannot decompose is a signal you do not understand it yet — which is itself worth reporting.

Give ranges, with the reason for the spread. "Three to eight days, depending on whether the existing export code can be reused" is honest and actionable. A single number implies a precision you do not have, and it is the number people will hold you to.

Estimate the whole job. Code is often less than half of it: review, tests, migration, deployment, docs, and the follow-up bugs are all real. Estimating only implementation is the single most common cause of overrun.

Separate uncertainty from padding. Padding hides the risk; naming it lets others act on it. "There's a real chance the third-party API doesn't support bulk updates — I can spike it in half a day and firm up the estimate" gives the person planning something they can actually use.

Re-estimate out loud when you learn something. The failure mode is silence until the deadline. An early "this is bigger than I thought, here's why" is a manageable problem; the same news on the due date is not.

Track your own calibration. Compare your estimates to reality for a while. Most engineers discover a consistent personal multiplier — knowing yours makes you dramatically more useful than being 'accurate' by luck.