prorise-cool/estimation

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:

1. Count each component type
2. Classify complexity (low/medium/high)
3. Apply weights
4. Calculate unadjusted function points
5. 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

1. Requirements are stable and complete
2. Team has 80% availability (20% overhead)
3. No major technology changes
4. Dependencies delivered on time
5. [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

1. [Assumption 1]
2. [Assumption 2]

### Risks Affecting Estimate

| Risk | Impact on Estimate |
|------|-------------------|
| [Risk 1] | +20% if occurs |
| [Risk 2] | +15% if occurs |

### Recommendations

1. [Next steps for refining estimate]
2. [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