Phase 5 of 5  ·  Management
Week 19 / 20   ·   Ch 23

Project Planning
& Estimation

"Why your 2-day estimate becomes a 2-week reality"

📚 Ch 23 — Project Planning🔮 COCOMO Model🃏 Planning Poker⏱ ~20 min read

🔍Concept Deep Dives

Click each concept to expand — real examples, diagrams, pros & cons.

🔮

Why Estimation is Hard

Scope creep, unknown unknowns, interruptions, optimism bias, complexity underestimation.
⌄

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
Hofstadter's Law: 'Everything takes longer than you think, even when you take Hofstadter's Law into account.' Cone of Uncertainty: Project start: estimate ±400% Requirements done: ±25% Design done: ±10% Implementation done: ±5%
🃏

Planning Poker & Story Points

Relative estimation using Fibonacci sequence. Team votes simultaneously — reveals disagreement, triggers discussion.
⌄

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)
Story Points (Fibonacci): 1, 2, 3, 5, 8, 13, 21 Velocity: avg story points completed per sprint Capacity: team availability × focus factor Forecast: backlog points ÷ velocity = sprints
📐

COCOMO Model

COnstructive COst MOdel. Algorithmic estimation based on lines of code (KLOC) and complexity factors.
⌄

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
COCOMO Basic: Effort = a × (KLOC)^b Duration = c × (Effort)^d Adjusted by 15 cost drivers: → Product (reliability, complexity) → Hardware (speed, storage) → Personnel (experience) → Project (tools, schedule)
📊

Velocity-Based Forecasting

Use past team velocity to forecast future delivery. More accurate than COCOMO for agile teams.
⌄

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
Sprint 1: 28 pts Sprint 2: 34 pts Sprint 3: 30 pts Sprint 4: 35 pts Avg Velocity: 32 pts/sprint Remaining backlog: 160 pts 160 ÷ 32 = 5 sprints remaining

📋Quick Reference

θ Ch 23 Cheat Sheet — Project Planning & Estimation
Cone of Uncertainty
Estimates improve as project progresses. At start: ±400%. After design: ±10%.
Story Points
Relative unit of effort. Fibonacci sequence. Team-specific — don't compare across teams.
Velocity
Average story points completed per sprint. Used for forecasting future delivery.
Planning Poker
Simultaneous voting to estimate. Disagreement triggers discussion. Reveals hidden complexity.
COCOMO
Algorithmic model: Effort = a × (KLOC)^b. For large, well-specified projects.
Hofstadter's Law
Everything takes longer than expected, even accounting for this law.
Buffer
Add 20-30% to estimates. Tasks always have unexpected complications.
θ
Sommerville's Key Points — Ch 23
Author's own summary from the end of the chapter.
  • 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.

🧠Quiz — Test Yourself

Think through your answer first, then reveal.

Q1
Recall
What is the Cone of Uncertainty? What does it imply for early project estimates?
The Cone of Uncertainty shows that estimates are most uncertain at the start and improve as the project progresses. At project start: ±4x (could be 25% or 400% of estimate). After requirements: ±25%. After design: ±10%. Implication: NEVER give a precise commitment at project start. Give a range, and tighten it as uncertainty reduces.
Q2
Apply
What is velocity in Scrum and how is it used for forecasting?
Velocity = average story points completed per sprint. After 3-4 sprints, you have a stable average. Forecasting: remaining backlog (story points) ÷ average velocity = estimated sprints to complete. Example: 200 story points remaining ÷ 40 pts/sprint = 5 sprints (10 weeks). More accurate than upfront estimates because it's based on actual team performance.
Q3
Analyze
Why do software projects consistently take longer than estimated?
Multiple causes: Scope creep (requirements expand). Optimism bias (developers estimate best case, not realistic case). Unknown unknowns (issues that couldn't be anticipated). Integration complexity (components don't work together as expected). External dependencies (APIs, third parties, other teams). Hofstadter's Law: everything takes longer, even accounting for this.
Up Next → Week 20
Quality & Configuration Management
ISO 9001, Git, Code Review — the boring stuff that saves projects
Continue → Week 20