Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
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.
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%)
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).
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.
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
Strip safety from individual estimates. Use 50%-confidence estimates (the median, not the pessimistic).
Identify the critical chain. Like the critical path, but including resource constraints (resource-leveled critical path).
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.
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).
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
Product Owner describes the user story.
Each developer privately selects a Fibonacci card representing their estimate.
All cards revealed simultaneously.
If estimates converge (e.g., all 5s and 8s), take the consensus.
If estimates diverge significantly (e.g., a 2 and a 13), the high and low estimators explain their reasoning.
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
Identify a reference class. Find a set of past projects similar to yours in type, scope, and context.
Obtain the distributional data. What were the actual durations/costs for the reference class?
Position your project within the distribution. Unless you have strong evidence for being above or below average, start at the median.
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:
Identify external dependencies in the WBS
Get written commitments with dates from external parties
Build fallback plans (mocks, stubs, alternative vendors) for each
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.
