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 visible
• Stakeholders understand it without training
• Shows resource loading over time

Limitations:

• Does not show uncertainty (every bar has crisp edges)
• Becomes unwieldy for large projects (100+ tasks require hierarchical grouping)
• Tempts teams into premature precision — a detailed Gantt chart implies a certainty that does not exist early in the project

Best practice. Use Gantt charts for communication, not for planning. Plan with the WBS and CPM. Render the plan as a Gantt chart for stakeholders.

Technique 5 — Resource Leveling

Problem. The CPM calculation assumes unlimited resources. In reality, the same developer cannot work on Tasks B and C simultaneously, even if both could start at day 3.

Resource leveling adjusts the schedule to respect resource constraints, potentially extending the project beyond the CPM duration.

Worked Example

From the CPM example above, suppose Developer 1 is assigned to both Task C (Product API, days 3-7) and Task G (Cart backend, days 7-10), and Developer 2 handles B and E. This works because C finishes before G starts.

But if Developer 1 is also assigned to Task F (Product UI, days 7-10, same as G), there is a conflict: one person cannot do F and G simultaneously. Resolution: shift F to start after G completes (day 10), making F run days 10-13 and H run days 13-17. New project duration: 22 days (3 days longer than CPM).

Lesson. Resource constraints often extend the schedule beyond the theoretical minimum. This is why planning tools that ignore resource loading produce fiction.

Technique 6 — Critical Chain Project Management (Goldratt)

Eliyahu Goldratt's Theory of Constraints, applied to project management, challenges conventional scheduling:

The Problem with Traditional Buffering

Traditional project management adds safety buffers to each task estimate. But Parkinson's Law ("work expands to fill the time available") and the Student Syndrome ("I'll start the night before") consume these buffers. Individual task buffers are wasted; the project still overruns.

Goldratt's Solution — Project Buffer

1. Strip safety from individual estimates. Use 50%-confidence estimates (the median, not the pessimistic).
2. Identify the critical chain. Like the critical path, but including resource constraints (resource-leveled critical path).
3. Add a project buffer. Aggregate the stripped safety into a single buffer at the end of the critical chain. Typically 50% of the chain duration.
4. Add feeding buffers. Non-critical chains feed into the critical chain. Place buffers where they join to protect the critical chain from delays on feeding chains.

Worked Example — Critical Chain Buffer Sizing

Traditional estimates for the critical chain:

Task	50% estimate	90% estimate (traditional)	Safety stripped
A	2.5 days	4 days	1.5 days
C	3.5 days	6 days	2.5 days
G	2.5 days	5 days	2.5 days
H	3 days	5 days	2 days
I	4 days	8 days	4 days

Critical chain at 50% estimates: 15.5 days.

Sum of stripped safety: 12.5 days. Project buffer = 50% of critical chain = 7.75 days (round to 8).

Total schedule: 15.5 + 8 = 23.5 days.

Compare to traditional: 4 + 6 + 5 + 5 + 8 = 28 days.

Savings: 4.5 days — and the project buffer is actively managed (visible, tracked), whereas traditional hidden buffers are silently consumed.

Buffer Management

Monitor buffer consumption versus project completion:

Zone	Buffer consumed	Project complete	Action
Green	0-33%	>33%	On track
Yellow	33-67%	<67%	Investigate, prepare recovery plan
Red	>67%	<90%	Activate recovery plan

If you are in the Green zone, no intervention needed. Yellow means look at the problem. Red means act. This traffic-light system gives managers a simple, honest signal — unlike traditional plans where everything is "on track" until the day before the deadline.

Technique 7 — Story Points, Velocity, and Planning Poker

Story Points

Story points measure relative effort, not absolute time. A story estimated at 8 points is roughly twice the work of a 4-point story. The Fibonacci scale (1, 2, 3, 5, 8, 13, 21) forces estimators to acknowledge that larger stories carry more uncertainty — the gap between 8 and 13 is intentionally large.

Velocity

Velocity is the average number of story points completed per sprint. After 3-5 sprints, velocity stabilizes and becomes the primary forecasting tool.

Forecasting with velocity. Total remaining story points / average velocity = expected sprints to completion.

Worked example. Backlog contains 120 story points. Average velocity over last 5 sprints: 28 points/sprint. Forecast: 120 / 28 = 4.3 sprints. With standard deviation of velocity (say, 4 points/sprint), the range is 120/(28+4) to 120/(28-4) = 3.75 to 5.0 sprints. Report to stakeholders: "4-5 sprints, with 4.3 as the most likely."

Planning Poker

1. Product Owner describes the user story.
2. Each developer privately selects a Fibonacci card representing their estimate.
3. All cards revealed simultaneously.
4. If estimates converge (e.g., all 5s and 8s), take the consensus.
5. If estimates diverge significantly (e.g., a 2 and a 13), the high and low estimators explain their reasoning.
6. Repeat until convergence. Usually 2-3 rounds.

Why it works. Simultaneous reveal prevents anchoring. Forced discussion surfaces hidden assumptions. The high estimator often knows about a complexity the others missed; the low estimator may know a shortcut.

Anti-pattern — estimation by averaging. If one person says 3 and another says 13, the answer is not 8. The answer is: "We don't agree on the scope. Let's talk about what's different in our mental models." The conversation is more valuable than the number.

Technique 8 — Reference Class Forecasting (Kahneman/Flyvbjerg)

The Problem: Inside View vs. Outside View

Daniel Kahneman and Amos Tversky demonstrated that people consistently underestimate task durations. The cause: the "inside view" — focusing on the specific task at hand and constructing a scenario where everything goes according to plan. The "outside view" asks: "How long did similar tasks actually take?"

Bent Flyvbjerg documented this empirically across thousands of infrastructure projects: cost overruns average 28% for IT projects, 34% for rail projects, 45% for bridges. The planning fallacy is universal and systematic.

The Method

1. Identify a reference class. Find a set of past projects similar to yours in type, scope, and context.
2. Obtain the distributional data. What were the actual durations/costs for the reference class?
3. Position your project within the distribution. Unless you have strong evidence for being above or below average, start at the median.
4. Adjust for specific factors. Only adjust for factors that are genuinely different from the reference class — not for optimism.

Worked Example

Task: Migrate a monolithic application to microservices.

Internal estimate (inside view): "Our team is experienced. The code is well-structured. 6 months."

Reference class (outside view): Flyvbjerg's database of 20 similar migrations:

• Median actual duration: 11 months
• 25th percentile: 8 months
• 75th percentile: 16 months
• Mean: 12.5 months

Adjustment: The codebase has unusually good test coverage (95%), reducing integration risk. Adjust to 25th percentile: 8 months.

Final estimate: 8 months (not 6). The reference class saved the project from a 2-month underestimate — 33% — which is exactly the typical planning fallacy magnitude Flyvbjerg documents.

Technique 9 — The Cone of Uncertainty

Steve McConnell documented that estimates narrow as a project progresses:

Phase	Estimate accuracy range
Initial concept	0.25x to 4x (actual could be 1/4 or 4x the estimate)
Approved product definition	0.5x to 2x
Requirements complete	0.67x to 1.5x
UI design complete	0.8x to 1.25x
Detailed design complete	0.9x to 1.1x

Implication. An initial estimate of "6 months" really means "1.5 to 24 months." Presenting it as "6 months" is dishonest precision. Present the range: "6-24 months, narrowing as we learn more."

Practical application. Re-estimate at each phase gate. Expect estimates to change — and communicate that expectation to stakeholders upfront. An estimate that does not narrow over time is a sign that the team is not learning (or not being honest about what they are learning).

GSD Connection — Wave Execution as Progressive Estimation

GSD's wave execution model naturally implements the cone of uncertainty. Each wave plans only the work that is well-understood enough to execute. Future waves are estimated at lower fidelity. As each wave completes, the next wave's estimates tighten based on actual velocity and discovered complexity.

The discuss phase gathers enough context to estimate the next phase — not the entire project. This is the Last Responsible Moment principle: estimate when you have the most information, not at the beginning when you have the least.

Schedule Compression

When the estimated schedule exceeds the deadline, two strategies exist:

Crashing

Add resources to critical path tasks to shorten their duration. This increases cost.

Rules:

• Only crash critical path tasks (crashing non-critical tasks does not shorten the project)
• Calculate crash cost per day saved; crash the cheapest tasks first
• Watch for diminishing returns — doubling developers does not halve duration (see Brooks's Law)

Fast-Tracking

Execute tasks in parallel that were originally planned sequentially. This increases risk.

Example. Begin coding before design is fully complete (overlap phases). Begin integration testing before all components are finished (test what is available).

Risk: Rework if the parallel task depends on output from the not-yet-complete predecessor. Fast-tracking is a gamble — it pays off when dependencies are weak, and punishes when dependencies are strong.

Worked Example — Compression Decision

Situation. Project estimate: 26 days. Deadline: 22 days. Must compress by 4 days.

Option	Days saved	Added cost	Added risk
Crash Task I (add 2 testers)	2	$8,000	Low
Fast-track H and E (parallel UI work)	2	$0	Medium (rework if cart API changes)
Crash Task C (add 1 backend dev)	1	$5,000	Low
Reduce scope (drop promo codes)	3	-$6,000	None

Selected combination: Crash Task I (-2 days, $8K), fast-track H and E (-2 days, medium risk). Total: -4 days. Risk is manageable with daily sync between UI teams. Cost: $8K.

Alternative: Reduce scope (-3 days) + crash Task I (-2 days). Saves $6K and compresses by 5 days with lower risk. This option is better if the Product Owner agrees promo codes can defer to the next release.

Brooks's Law — "Adding People to a Late Project Makes It Later"

Fred Brooks observed that new team members impose costs:

• Ramp-up time. Learning the codebase, tools, conventions, and domain.
• Communication overhead. n people require n(n-1)/2 communication paths.
• Training burden. Existing team members must stop building to teach.

When Brooks's Law applies: Midway through a project, when the codebase is complex and domain knowledge is specialized.

When it doesn't apply: Very early in a project (before significant complexity accumulates), or when adding specialists for independent, isolated tasks (e.g., adding a DBA to handle database migration while the team continues feature work).

Practical implication. If the schedule is at risk, consider scope reduction or deadline extension before adding people. If you must add people, add them to non-critical-path tasks that are well-isolated and do not require deep context.

Milestone Planning and Dependency Management

Milestones

A milestone is a zero-duration marker that represents the completion of a significant deliverable. Milestones are decision gates: at each one, the team and stakeholders assess progress and decide whether to continue, adjust, or stop.

Good milestones:

• Binary (done or not done, no "80% complete")
• Tied to deliverables, not dates ("Auth system passes pen test" not "End of sprint 6")
• Spaced 2-4 weeks apart (frequent enough for early warning, infrequent enough to avoid overhead)

Dependency Types

Type	Description	Example
Finish-to-Start (FS)	B cannot start until A finishes	Testing cannot start until coding finishes
Start-to-Start (SS)	B cannot start until A starts	Design review starts when design starts
Finish-to-Finish (FF)	B cannot finish until A finishes	Documentation finishes when coding finishes
Start-to-Finish (SF)	B cannot finish until A starts	(Rare) Legacy system runs until new system launches

FS is the default and most common. Use SS and FF deliberately for overlapping activities. SF is almost never used in software.

External Dependencies

External dependencies (vendor deliverables, regulatory approvals, third-party integrations) are the highest-risk dependencies because the team does not control them.

Mitigation pattern:

1. Identify external dependencies in the WBS
2. Get written commitments with dates from external parties
3. Build fallback plans (mocks, stubs, alternative vendors) for each
4. Track external milestones weekly — do not wait for the deadline to discover a slip

When to Use / When NOT to Use

When to use formal estimation and planning

• Projects longer than 2 weeks with schedule commitments
• Multiple people or teams who need to coordinate
• Stakeholders who need forecasts for business decisions
• Any situation where "how long will this take?" has consequences

When NOT to use formal estimation and planning

• Exploratory work where the scope is genuinely unknown (spike first, estimate second)
• Small, well-understood tasks that one person will complete in a day
• When planning becomes a substitute for doing — the plan is not the product
• When estimates are treated as commitments (estimates are forecasts with uncertainty; commitments are promises)

The estimation paradox

The time to estimate is when you know the least. The accuracy of estimates peaks when you know the most (end of the project). This is why re-estimation is not failure — it is learning. Any organization that locks the initial estimate and punishes changes is guaranteeing dishonest estimates.

Cross-References

• gantt agent: Primary agent for planning, scheduling, and estimation. Gantt charts, WBS, CPM, PERT.
• goldratt agent: Theory of Constraints, critical chain project management, buffer management, bottleneck identification.
• brooks agent: Department chair. Brooks's Law, communication overhead, schedule risk from team scaling.
• hamilton agent: Systems engineering estimation — integration complexity, interface estimation, V&V scheduling.
• agile-methods skill: Story points, velocity, planning poker — Agile estimation techniques that complement the classical methods here.
• risk-management skill: Monte Carlo simulation for schedule risk, risk-adjusted planning, contingency reserves.
• quality-assurance skill: Quality gates as milestones, testing schedule within the overall project plan.

References

• Brooks, F. P. (1975/1995). The Mythical Man-Month. Addison-Wesley.
• Goldratt, E. M. (1997). Critical Chain. North River Press.
• McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Microsoft Press.
• Kahneman, D. & Tversky, A. (1979). "Intuitive Prediction: Biases and Corrective Procedures." Management Science, 12, 313-327.
• Flyvbjerg, B. (2006). "From Nobel Prize to Project Management: Getting Risks Right." Project Management Journal, 37(3), 5-15.
• Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall.
• PMI. (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide). 7th edition. Project Management Institute.
• Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. North River Press.
• Poppendieck, M. & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley.