Key Concepts
Estimation is hard. Understanding why it's hard — and using the right techniques — is the difference between reliable and chaotic delivery.
Why Estimation is Hard
Scope creep, unknown unknowns, interruptions, optimism bias, complexity underestimation.
Planning Poker & Story Points
Relative estimation using Fibonacci sequence. Team votes simultaneously — reveals disagreement, triggers discussion.
COCOMO Model
COnstructive COst MOdel. Algorithmic estimation based on lines of code (KLOC) and complexity factors.
Velocity-Based Forecasting
Use past team velocity to forecast future delivery. More accurate than COCOMO for agile teams.
Concept Deep Dives
Click each concept to expand — real examples, diagrams, pros & cons.
Why Estimation is Hard
When to Use
Understanding this prevents promising what you can't deliver.
Real-World Example
The Standish Group CHAOS Report: 66% of software projects are over budget or behind schedule.
✓ Advantages
- Understanding the causes lets you mitigate them
⚠ Watch Out
- No silver bullet — estimation will always be imprecise
Planning Poker & Story Points
When to Use
Sprint planning in Scrum. Estimating user stories before committing to a sprint.
Real-World Example
Team estimates user story: devs vote 3, 8, 13. Discuss why 13 — uncovers hidden complexity. Revote: 8. Done.
✓ Advantages
- Relative estimates more accurate than absolute
- Reveals hidden disagreements
- Fast with practice
⚠ Watch Out
- Calibration needed
- Velocity varies by team
- Story points ≠ hours (explain to stakeholders)
COCOMO Model
When to Use
Large projects where historical data and detailed specs exist. Government/defense contracts.
Real-World Example
NASA, defense contractors use COCOMO for large-scale system estimation where contracts require formal estimates.
✓ Advantages
- Systematic and repeatable
- Good for large, well-understood projects
- Historical calibration
⚠ Watch Out
- LOC hard to estimate before coding
- Many adjustment factors are subjective
- Not great for agile projects
Velocity-Based Forecasting
When to Use
Ongoing agile projects with ≥3 sprints of historical velocity data.
Real-World Example
Team average: 32 points/sprint. Backlog: 160 points. Forecast: ~5 sprints (10 weeks) to complete.
✓ Advantages
- Based on actual team performance
- Improves as more data available
- Accounts for team-specific factors
⚠ Watch Out
- New teams have no history
- Velocity changes with team changes
- Doesn't account for scope changes
Quick Reference
- 1Estimation is inherently uncertain — the Cone of Uncertainty.
- 2Algorithmic models: COCOMO uses LOC and complexity factors.
- 3Expert judgment + analogy: compare to similar past projects.
- 4Story points + velocity: relative estimation, improves with history.
- 5Planning poker: team estimation with Fibonacci sequence.
- 6Software pricing: cost + profit + market factors. Not just effort × rate.
- 7Always add contingency — Hofstadter's Law is always right.
From the Book & Beyond
Case Study — PharmaSoft's "Pricing to Win"
Section 23.1 opens with PharmaSoft, a 10-engineer company with contracts to keep only five busy. It's bidding for a huge pharmaceutical contract — 30 person-years of effort over two years — that won't start for at least 12 months. Meanwhile, a 10-month, six-person project comes up, costed at $1.2 million including overheads. PharmaSoft bids $0.8 million, deliberately losing money, because keeping its specialist staff together for the bigger prize is worth more than short-term profit. Sommerville's lesson: price is never just cost plus profit — it's shaped by market opportunity, financial health, and strategy. He calls it "pricing to win."
2026 Perspective — Monte Carlo, #NoEstimates & AI Planning
Estimates still fail for exactly the reason Sommerville names: you're estimating the unknown with incomplete information — and his suggested 30-50% contingency hasn't gone out of style. What's changed is the tooling. Probabilistic (Monte Carlo) forecasting — simulating delivery dates from your team's historical cycle times — increasingly replaces single-point estimates, while the #NoEstimates camp argues for slicing work small and simply counting throughput. AI assistants now draft work breakdowns and flag risky dependencies, but they can't fix optimistic assumptions. The planning game survives because its real output isn't a number — it's shared understanding.
Quiz — Test Yourself
Think through your answer first, then reveal.