Estimation and Planning
Estimation is the act of predicting the future with incomplete information. It is inherently uncertain, and the only dishonest estimate is one presented without uncertainty bounds. The history of software projects is a history of estimation failure — the Standish Group's CHAOS reports consistently show that the majority of projects overrun their schedules and budgets. This is not because developers are bad at estimation; it is because human cognition systematically underestimates complexity, and organizational incentives systematically punish honest estimates.
This skill catalogs estimation and planning techniques that confront these realities: techniques that quantify uncertainty rather than hiding it, that use historical data rather than optimism, and that plan for what will actually happen rather than what we hope will happen.
Agent affinity: gantt (planning/estimation), goldratt (constraints/scheduling)
Concept IDs: bus-business-planning, bus-cost-benefit-analysis, crit-problem-analysis, crit-quantitative-reasoning
Estimation and Planning Toolbox
| # | Technique | Best for | Key insight | |---|---|---|---| | 1 | Work Breakdown Structure | Scope decomposition | You cannot estimate what you have not decomposed | | 2 | Critical Path Method | Schedule analysis | The longest path determines the shortest possible duration | | 3 | PERT Estimation | Duration uncertainty | Three-point estimates capture uncertainty mathematically | | 4 | Gantt Charts | Visual scheduling | Dependencies and parallelism made visible | | 5 | Resource Leveling | Capacity planning | People are not fungible; availability constrains the schedule | | 6 | Critical Chain (Goldratt) | Buffer management | Protect the project, not individual tasks | | 7 | Story Points / Velocity | Agile estimation | Relative sizing is more accurate than absolute duration | | 8 | Reference Class Forecasting | Debiasing estimates | Look at how similar projects actually performed | | 9 | Cone of Uncertainty | Estimate maturation | Estimates improve as you learn; plan for this |
Technique 1 — Work Breakdown Structure (WBS)
Pattern: Decompose the project scope into progressively smaller, manageable components until each leaf node is estimable and assignable.
The 100% rule. The WBS must include 100% of the work defined by the project scope. Nothing is hidden in "miscellaneous" or "other." If it is not in the WBS, it is not in the project.
Decomposition heuristic. Stop decomposing when a work package:
- Can be estimated with reasonable confidence (uncertainty under 50%)
- Takes 1-2 weeks or less to complete
- Can be assigned to a single person or small team
- Has a clear definition of done
Worked Example — Web Application WBS
1. E-Commerce Platform
1.1 User Authentication
1.1.1 Login/logout flow
1.1.2 Registration with email verification
1.1.3 Password reset
1.1.4 OAuth integration (Google, GitHub)
1.1.5 Session management
1.2 Product Catalog
1.2.1 Product listing page
1.2.2 Product detail page
1.2.3 Category navigation
1.2.4 Search with filters
1.2.5 Image gallery
1.3 Shopping Cart
1.3.1 Add/remove items
1.3.2 Quantity adjustment
1.3.3 Cart persistence (logged-in and guest)
1.3.4 Promo code application
1.4 Checkout
1.4.1 Shipping address entry
1.4.2 Payment processing
1.4.3 Order confirmation
1.4.4 Email receipt
1.5 Admin Panel
1.5.1 Product CRUD
1.5.2 Order management
1.5.3 User management
1.5.4 Analytics dashboard
1.6 Infrastructure
1.6.1 CI/CD pipeline
1.6.2 Database setup and migration
1.6.3 Staging environment
1.6.4 Production deployment
1.6.5 Monitoring and alerting
Total work packages: 23. Each is estimable. The WBS exposes scope that a one-line description ("build an e-commerce platform") hides — infrastructure alone has 5 work packages that a developer might not mention until sprint 4.
Technique 2 — Critical Path Method (CPM)
Pattern: Build a network diagram of tasks with dependencies. The critical path is the longest path through the network — it determines the minimum project duration. Any delay on the critical path delays the entire project.
Key terms:
- ES (Early Start): Earliest time a task can begin
- EF (Early Finish): ES + Duration
- LS (Late Start): Latest time a task can begin without delaying the project
- LF (Late Finish): LS + Duration
- Float (Slack): LS - ES. Tasks on the critical path have zero float.
Worked Example — CPM Calculation
| Task | Duration (days) | Dependencies | |---|---|---| | A: Database schema | 3 | None | | B: Auth backend | 5 | A | | C: Product API | 4 | A | | D: Frontend shell | 3 | None | | E: Auth UI | 4 | B, D | | F: Product UI | 3 | C, D | | G: Cart backend | 3 | C | | H: Cart UI | 4 | F, G | | I: Integration testing | 5 | E, H |
Forward pass (earliest times):
| Task | ES | EF | |---|---|---| | A | 0 | 3 | | B | 3 | 8 | | C | 3 | 7 | | D | 0 | 3 | | E | 8 | 12 | | F | 7 | 10 | | G | 7 | 10 | | H | 10 | 14 | | I | 14 | 19 |
Project duration: 19 days.
Backward pass (latest times):
| Task | LS | LF | Float | |---|---|---|---| | A | 0 | 3 | 0 | | B | 3 | 8 | 0 | | C | 3 | 7 | 0 | | D | 5 | 8 | 5 | | E | 10 | 14 | 2 | | F | 7 | 10 | 0 | | G | 7 | 10 | 0 | | H | 10 | 14 | 0 | | I | 14 | 19 | 0 |
Critical path: A -> C -> G -> H -> I (19 days). Also A -> C -> F -> H -> I (19 days). Two parallel critical paths.
Key insight. Task D (Frontend shell) has 5 days of float — it can slip 5 days without affecting the project. Task E (Auth UI) has 2 days of float. But tasks A, C, G, H, and I have zero float. Any slip on these tasks delays the project day-for-day.
Management action. Assign the strongest developers to critical path tasks. Do not interrupt people working on the critical path. Put buffer and contingency on the critical path, not on float tasks.
Technique 3 — PERT Estimation
Pattern: For each task, provide three estimates: Optimistic (O), Most Likely (M), Pessimistic (P). The PERT formula produces a weighted mean and standard deviation.
PERT mean: E = (O + 4M + P) / 6
PERT standard deviation: sigma = (P - O) / 6
The formula weights the most likely estimate 4x, creating a beta distribution that models the positive skew typical of task durations (things go wrong more often than they go better than expected).
Worked Example — PERT for Critical Path Tasks
| Task | O (days) | M (days) | P (days) | E (days) | sigma | |---|---|---|---|---|---| | A: Database schema | 2 | 3 | 6 | 3.33 | 0.67 | | C: Product API | 3 | 4 | 9 | 4.67 | 1.00 | | G: Cart backend | 2 | 3 | 8 | 3.67 | 1.00 | | H: Cart UI | 3 | 4 | 7 | 4.33 | 0.67 | | I: Integration testing | 3 | 5 | 12 | 5.83 | 1.50 |
Critical path PERT mean: 3.33 + 4.67 + 3.67 + 4.33 + 5.83 = 21.83 days
Critical path standard deviation: sqrt(0.67^2 + 1.00^2 + 1.00^2 + 0.67^2 + 1.50^2) = sqrt(0.45 + 1.00 + 1.00 + 0.45 + 2.25) = sqrt(5.15) = 2.27 days
Probability-based scheduling:
- 50% confidence: 21.83 days (the mean)
- 68% confidence: 21.83 + 2.27 = 24.1 days (1 sigma)
- 85% confidence: 21.83 + 2.27 * 1.04 = 24.2 days
- 95% confidence: 21.83 + 2.27 * 1.65 = 25.6 days
Translation for stakeholders. "If you want 50/50 odds of making the deadline, schedule 22 days. If you need 95% confidence, schedule 26 days. The 4-day difference is not padding — it is mathematical uncertainty."
Technique 4 — Gantt Charts
A Gantt chart is a horizontal bar chart where each bar represents a task, the x-axis is time, and dependencies are shown as connecting lines. Henry Gantt developed the format in the 1910s; it remains the most widely used schedule visualization.
Strengths:
- Instantly shows parallelism and sequencing
- Makes the critical path