Estimation
When to Use This Skill
Use this skill when:
-
Estimation tasks - Working on estimation techniques including analogous, parametric, three-point, and expert judgment methods. provides effort, cost, duration, and complexity estimates for projects, features, and tasks
-
Planning or design - Need guidance on Estimation approaches
-
Best practices - Want to follow established patterns and standards
Overview
Systematically estimate effort, cost, duration, and complexity using proven estimation techniques. Supports analogous, parametric, three-point (PERT), and expert judgment methods for projects, features, and tasks.
What is Estimation?
Estimation is the process of forecasting the resources, time, and cost required to complete work. Good estimation balances:
-
Accuracy: How close to actual results
-
Precision: Consistency of estimates
-
Speed: Time to produce estimates
-
Communication: Shared understanding of uncertainty
Estimation vs Commitment
Concept Definition Use
Estimate Best guess given current knowledge Planning, forecasting
Commitment Promise to deliver by date/cost Contracts, deadlines
Target Desired outcome to aim for Goals, objectives
Key principle: Estimates are ranges with uncertainty, not single-point guarantees.
Estimation Techniques
Analogous Estimation (Top-Down)
Estimate based on similar past work:
Step Action
1 Identify similar completed project/feature
2 Retrieve actual effort/cost/duration
3 Adjust for differences (complexity, team, technology)
4 Apply adjustment factor
Formula:
New Estimate = Historical Actual × Adjustment Factor
Example: Similar project took 200 hours New project is ~20% more complex Estimate = 200 × 1.20 = 240 hours
When to Use: Early phases, limited detail, experienced teams with historical data
Accuracy: +/- 25-50% (improves with good historical data)
Parametric Estimation
Estimate using statistical relationships:
Element Description
Unit of Work Measurable element (screen, API, table)
Productivity Rate Effort per unit from historical data
Quantity Number of units to produce
Formula:
Estimate = Quantity × Productivity Rate
Example: 10 API endpoints × 16 hours/endpoint = 160 hours
Common Productivity Metrics:
Work Type Metric Typical Range
UI screens Hours/screen 8-40 hours
API endpoints Hours/endpoint 4-24 hours
Database tables Hours/table 4-16 hours
Test cases Hours/test 0.5-4 hours
Documentation pages Hours/page 2-8 hours
When to Use: Repeatable work, good historical data, similar technology
Accuracy: +/- 15-25% (with calibrated rates)
Three-Point Estimation (PERT)
Estimate using optimistic, most likely, and pessimistic values:
Value Symbol Definition
Optimistic O Best case, everything goes right
Most Likely M Most probable outcome
Pessimistic P Worst case, problems occur
PERT Formula (Weighted Average):
Expected = (O + 4M + P) / 6 Standard Deviation = (P - O) / 6
Example: O = 5 days, M = 8 days, P = 17 days Expected = (5 + 4×8 + 17) / 6 = 9 days Std Dev = (17 - 5) / 6 = 2 days
Confidence Intervals:
Confidence Calculation Example (E=9, SD=2)
68% E ± 1 SD 7-11 days
95% E ± 2 SD 5-13 days
99.7% E ± 3 SD 3-15 days
When to Use: Uncertain work, new technology, need to communicate risk
Accuracy: Provides explicit uncertainty range
Expert Judgment
Estimate using collective expert knowledge:
Wideband Delphi Process:
Round Activity
1 Experts estimate independently
2 Collect and share anonymous estimates
3 Discuss high/low outliers, share rationale
4 Re-estimate independently
5 Repeat until convergence (or average)
Planning Poker (Agile):
Step Action
1 Present item to estimate
2 Discuss briefly (2-5 minutes)
3 Each team member selects card privately
4 Reveal simultaneously
5 Discuss outliers
6 Re-vote until consensus
Common Scales:
Scale Type Values
Fibonacci 1, 2, 3, 5, 8, 13, 21, 34, 55, 89
Modified Fibonacci 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100
T-shirt XS, S, M, L, XL, XXL
Powers of 2 1, 2, 4, 8, 16, 32, 64
When to Use: Complex work, multiple perspectives needed, team alignment
Function Point Analysis
Estimate based on functional size (for larger systems):
Component Description Weight Range
External Inputs Data entering system 3-6
External Outputs Data leaving system 4-7
External Inquiries Read-only queries 3-6
Internal Files Logical data stores 7-15
External Interfaces Shared data 5-10
Process:
-
Count each component type
-
Classify complexity (low/medium/high)
-
Apply weights
-
Calculate unadjusted function points
-
Apply technical complexity factor
When to Use: Large projects, formal contracts, industry benchmarking
Relative Estimation
Story Points
Relative complexity/effort measure:
Points Relative Size Example
1 Trivial Fix typo, config change
2 Simple Simple bug fix, minor feature
3 Moderate Standard feature, moderate complexity
5 Complex Multi-component feature
8 Very complex Integration work, significant unknowns
13 Epic-sized Consider breaking down
21+ Too large Must decompose
Baseline: Pick a well-understood story as reference (e.g., "this is a 3")
Velocity: Story points completed per iteration (used for forecasting)
T-Shirt Sizing
Quick relative sizing for roadmap planning:
Size Effort Range Duration Range
XS 1-4 hours < 1 day
S 0.5-2 days 1-2 days
M 2-5 days 3-5 days
L 1-2 weeks 1-2 weeks
XL 2-4 weeks 2-4 weeks
XXL 1-3 months Too big, decompose
Workflow
Phase 1: Prepare
Step 1: Clarify Scope
Estimation Request
Item: [What's being estimated] Requester: [Who needs the estimate] Purpose: [Planning/budgeting/commitment] Deadline: [When estimate is needed] Precision: [ROM/Budget/Definitive]
Scope Definition
- In Scope: [What's included]
- Out of Scope: [What's excluded]
- Assumptions: [Key assumptions]
- Constraints: [Known constraints]
Step 2: Select Estimation Technique
Situation Recommended Technique
Early project phase Analogous + T-shirt sizing
Detailed requirements Parametric + Three-point
Agile backlog Story points + Planning poker
New technology/domain Expert judgment + Three-point
Contract/budget Function points + Parametric
Phase 2: Estimate
Step 1: Decompose Work
Break down into estimable units (half-day to 2-week chunks)
Step 2: Apply Technique
Use selected technique(s) from above
Step 3: Add Contingency
Contingency Calculation
| Risk Level | Contingency | When to Use |
|---|---|---|
| Low | 10-15% | Well-understood, experienced team |
| Medium | 20-30% | Some unknowns, new team members |
| High | 40-50% | Significant unknowns, new technology |
| Very High | 75-100% | Research, innovation, first-of-kind |
Step 4: Validate
-
Sanity check against similar work
-
Review with team
-
Check for missing items
-
Verify assumptions
Phase 3: Communicate
Step 1: Express as Range
Estimate Summary
Effort: 160-200 hours (confidence: 80%) Duration: 4-5 weeks (with 2 developers) Cost: $24,000-$30,000
Key Risks:
- API integration complexity unknown
- Dependency on third-party availability
Step 2: Document Assumptions
Estimation Assumptions
- Requirements are stable and complete
- Team has 80% availability (20% overhead)
- No major technology changes
- Dependencies delivered on time
- [Additional assumptions...]
If assumptions change, estimate should be revisited.
Output Formats
Narrative Summary
Estimation Summary
Item: [Feature/Project name] Date: [ISO date] Estimator: estimation-analyst Technique: [Technique used]
Estimate
| Dimension | Low | Expected | High | Confidence |
|---|---|---|---|---|
| Effort | 120h | 160h | 220h | 80% |
| Duration | 4w | 5w | 7w | 80% |
| Cost | $18K | $24K | $33K | 80% |
Basis of Estimate
- Historical Reference: [Similar past work]
- Productivity Rate: [If parametric]
- Expert Input: [Who contributed]
Assumptions
- [Assumption 1]
- [Assumption 2]
Risks Affecting Estimate
| Risk | Impact on Estimate |
|---|---|
| [Risk 1] | +20% if occurs |
| [Risk 2] | +15% if occurs |
Recommendations
- [Next steps for refining estimate]
- [When to re-estimate]
Structured Data (YAML)
estimation: version: "1.0" date: "2025-01-15" item: "User Dashboard Feature" estimator: "estimation-analyst" technique: "three_point"
scope: description: "Interactive user dashboard with analytics" in_scope: - "Dashboard UI components" - "Data visualization" - "User preferences" out_of_scope: - "Backend analytics engine" - "Real-time updates" assumptions: - "API endpoints available" - "Design mockups complete"
estimates: effort: optimistic: 120 most_likely: 160 pessimistic: 240 expected: 166 unit: "hours" std_deviation: 20 duration: optimistic: 3 most_likely: 4 pessimistic: 6 expected: 4.2 unit: "weeks" cost: expected: 24000 range_low: 18000 range_high: 36000 currency: "USD"
confidence: 0.80 contingency: 0.20
breakdown: - component: "UI Components" effort: 60 technique: "parametric" rate: "15h/component" quantity: 4 - component: "Data Integration" effort: 40 technique: "analogous" reference: "PROJ-123" - component: "Testing" effort: 40 technique: "percentage" percentage: 0.25
risks: - risk: "API complexity higher than expected" probability: 0.3 impact_hours: 30 - risk: "Design changes during development" probability: 0.2 impact_hours: 20
historical_comparison: similar_item: "Admin Dashboard" actual_effort: 180 adjustment_factor: 0.9
Breakdown Table
Effort Breakdown
| Component | Technique | Estimate | Contingency | Total |
|---|---|---|---|---|
| UI Components | Parametric | 60h | 12h | 72h |
| Data Integration | Analogous | 40h | 10h | 50h |
| Testing | % of Dev | 40h | 8h | 48h |
| Documentation | Parametric | 16h | 4h | 20h |
| Subtotal | 156h | 34h | 190h | |
| Management Overhead | 10% | 19h | ||
| Total | 209h |
Estimation Accuracy
Cone of Uncertainty
Estimate accuracy improves as project progresses:
Phase Accuracy Range
Initial concept 0.25x - 4x
Approved project 0.5x - 2x
Requirements complete 0.67x - 1.5x
Detailed design 0.8x - 1.25x
Code complete 0.9x - 1.1x
Implication: Early estimates need wider ranges; refine as knowledge grows.
Estimation Levels
Level Accuracy When Used
ROM (Rough Order of Magnitude) -25% to +75% Initial budgeting
Budget -10% to +25% Project approval
Definitive -5% to +10% Execution baseline
Common Pitfalls
Pitfall Prevention
Single-point estimates Always provide ranges
Optimism bias Use historical data, add contingency
Anchoring Estimate before seeing others' estimates
Planning fallacy Include realistic overhead and risks
Scope creep Document assumptions, re-estimate on changes
Precision theater Match precision to actual knowledge
Integration
Upstream
-
Requirements - What to estimate
-
risk-analysis - Risks affecting estimates
-
stakeholder-analysis - Who needs estimates, precision required
Downstream
-
Project planning - Resource allocation, scheduling
-
Budgeting - Cost forecasting
-
prioritization - Cost input for value/effort analysis
Related Skills
-
risk-analysis
-
Risks affecting estimates
-
prioritization
-
Using estimates for prioritization
-
decision-analysis
-
Trade-off decisions
-
value-stream-mapping
-
Estimating process improvement effort
Version History
- v1.0.0 (2025-12-26): Initial release