Estimation and planning

Every estimate is a forecast under uncertainty. Software is mostly new work: if you had done the exact same thing before, you would copy it. So single-point promises ("done Friday") systematically lie.

The skill is not predicting the future to the day. It is decomposing work, expressing uncertainty, attacking unknowns early, and updating the forecast when reality disagrees. That is how you own a multi-week project without becoming the person who "always slips but never warns."

A fuzzy but honest range with named risks beats a precise date you do not believe — every time.

Concepts in this section

Read them in order. Each one builds on the one before.

Step	Concept	What it answers
1	Estimate vs commitment	Are they asking for a forecast or a date?
2	Work breakdown and spikes	How small do tasks get, and what do you do with unknowns?
3	Estimate ranges and padding	How do you quote uncertainty out loud?
4	De-risking and milestones	What do you build first, and what does "done" look like mid-project?
5	Evidence-based scheduling	How do you use your own history?
6	Communicating slips	What do you say when the plan moves?

The design doc names what and why. This section names when and in what order. Project execution is the weekly rhythm once the plan exists.

A three-week feature, in one picture

PM asks: "Can we ship shared report folders by the 28th?" Today is the 4th.

Spike first: reuse group ACLs, add folder_id, no new auth service. Raw breakdown sums to 10 eng-days. Calibrate the unfamiliar ACL line and the rest → about 13 eng-days, roughly 3 calendar weeks with meetings. Junior help on UI does not cut ACL risk.

The honest answer is a scope negotiation: internal dogfood by the 21st and external by the 28th if email-share slips to v2. If email-share is required, the date moves.

That is estimation doing its real job. Your calendar is not eight hours of coding: many ICs get 4–5 focus hours a day and lose a day a week to interrupts, so a "5 eng-day" task is often two calendar weeks.

Common mistakes

Estimating in story points that never convert to calendar time anyone believes.
Padding secretly instead of stating uncertainty.
Estimating only coding time.
Starting the easy work first.
Treating the first estimate as sacred.
Saying "yes" to a date without a breakdown.
Planning as if you have eight focus hours a day.

Key takeaways

Estimates fail from unknowns, optimism, integration/review time, and moving scope — not from moral failure.
Break work to ≤2-day tasks; spike unknowns before you pretend to know their cost.
Quote ranges and confidence; multiply consciously for unfamiliarity.
Schedule the riskiest work first; use milestones that ship value incrementally.
Renegotiate scope or date early with clear options; track estimate vs actual to calibrate yourself.