# Estimation and Planning — Part 1: Forecasts You Can Defend

"How long will it take?" is the question engineers dread. Seniors answer it with **ranges and assumptions**, break work down until the unknowns are visible, and re-plan openly as they learn. Interviewers ask how you estimate, and how you handled a project that ran late.

![Cone of uncertainty: estimates narrow as unknowns are resolved](diagrams/01-cone.svg)

## 1. Why Estimates Go Wrong

- **Unknown unknowns**: integrations, legacy behaviour, data quality.
- **Forgotten work**: tests, reviews, migrations, rollout, documentation, on-call fixes.
- **Optimism and anchoring**: the first number said in the room sticks.
- **Interruptions**: incidents, meetings, support; nobody codes 8 hours a day.
- **Treating estimates as commitments** so people pad silently or hide slips.

## 2. Techniques

| Technique | How |
|---|---|
| **Decompose** | Break work into pieces of at most a few days. Unknowns become visible as pieces you can't size. |
| **Spike first** | Time-box research on the riskiest unknown before estimating it. |
| **Three-point (PERT)** | For each piece: optimistic *O*, most likely *M*, pessimistic *P*. Expected = (O + 4M + P) / 6, standard deviation ≈ (P − O) / 6. |
| **Reference class** | "Our last three integrations took 3–5 weeks"; past data beats intuition. |
| **Relative sizing** | Story points or T-shirt sizes compared with known work, calibrated by velocity. |
| **Focus factor** | Real productive time is often 50–70% of calendar time. |

Communicate a **range with a confidence level**: "6–9 weeks, 80% confident, assuming the payment API supports refunds; we'll know after next week's spike."

## 3. Planning a Project

1. **Milestones** that deliver something demonstrable (a vertical slice end to end first).
2. **Riskiest work first**, so surprises arrive early.
3. **Dependencies** on other teams identified and agreed up front.
4. **Buffers** at the project level, not hidden in every task.
5. **Visible tracking**, weekly status with risks, and **early escalation** when slipping.
6. **Re-estimate** at each milestone; narrow the range as unknowns resolve.

## 4. When You're Running Late

Say so as soon as you know. Present options: **cut scope** (what's the minimum valuable release?), **move the date**, or **add people** (rarely helps late: Brooks's law). Let the stakeholder choose with clear trade-offs.

## Common Pitfalls

1. **Single-number estimates** with no assumptions.
2. **Estimating only coding time.**
3. **Anchoring** on a manager's hoped-for date.
4. **Hiding slips** until the deadline.
5. **Never comparing estimates with actuals**, so estimates never improve.

## Quick Reference

```text
Decompose to ≤ few days · spike the riskiest unknown · PERT: (O + 4M + P) / 6, σ ≈ (P − O) / 6
Communicate ranges + confidence + assumptions; use reference classes and focus factor (50–70%)
Plan: vertical slice first, risk first, dependencies agreed, project-level buffer, weekly status
Late? Tell early; offer cut scope / move date; adding people late rarely helps
```