Estimation and Planning
Seniors answer 'how long will it take?' with ranges and assumptions, break work down until the unknowns are visible, and re-plan openly. Learn why estimates fail, practical techniques including three-point estimation, how to plan a project, and what to do when it runs late.
🎯 What you'll learn
- Why estimates go wrong
- Decomposition, spikes and three-point estimation
- Planning milestones, risks and buffers
- Handling a project that runs late
📚 Before you start
"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.
1Why 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.
2Techniques
| 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."
3Planning a Project
- Milestones that deliver something demonstrable (a vertical slice end to end first).
- Riskiest work first, so surprises arrive early.
- Dependencies on other teams identified and agreed up front.
- Buffers at the project level, not hidden in every task.
- Visible tracking, weekly status with risks, and early escalation when slipping.
- Re-estimate at each milestone; narrow the range as unknowns resolve.
4When 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
- Single-number estimates with no assumptions.
- Estimating only coding time.
- Anchoring on a manager's hoped-for date.
- Hiding slips until the deadline.
- Never comparing estimates with actuals, so estimates never improve.
📋 Quick Reference
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🧠 Key takeaways
- Give ranges with confidence and assumptions, not single numbers.
- Decompose and spike the riskiest unknowns first.
- Use PERT, reference classes and a focus factor.
- When late, tell early and offer scope vs date trade-offs.
🛠️ Practice exercises
Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.
✅ Check yourself
Answer the questions — feedback is instant.