Estimating Software Work Realistically

Estimates are infamously bad in software. Most estimation methods are either too optimistic, too elaborate, or pretend to be precise when they are not. Here is the practical approach that has worked for me.

Estimate ranges, not points

"Two weeks" is wrong. "Between 1 and 4 weeks, most likely 2.5 weeks" is honest. Single-number estimates pretend you know what you do not know. Stakeholders eventually learn that 2 weeks means "between 1 and 5 weeks" anyway — make the range explicit.

Ask what's behind the unknowns

If a task involves "integrating with their API," you do not know how long it takes until you have read their docs. If it involves "refactoring the auth module," you do not know until you have looked at the auth module. Spend an hour or two on the unknowns before estimating, even informally.

Multiply by 1.5 to 2x for new tech

Anything you have done before, estimate based on past experience. Anything new — new framework, new domain, new integration — multiply your gut estimate by 1.5 or 2. The unknown unknowns are the cost.

Update estimates as you learn

An estimate is not a contract. As you start the work and discover things, update the estimate and tell stakeholders. "I now think this will take an extra week because of X" is far better than silently going over and announcing it on the deadline. The earlier the update, the more options exist for the team.

Track your error rate

Over time, you will discover your personal estimation bias — usually optimistic. Knowing yours ("I tend to underestimate by 40%") is more useful than any methodology. Most senior developers are calibrated through scar tissue, not technique.