Estimation Guide

1  - Trivial. Well-understood. A few hours of work at most.
2  - Small. Clear requirements. Straightforward implementation.
3  - Small-to-Medium. Some complexity. May involve a few components.
5  - Medium. Moderate complexity. Multiple components or some unknowns.
8  - Large. Significant complexity. Multiple integration points. Some risk.
13 - Very Large. High complexity. Significant unknowns. Should consider splitting.
21 - Epic-sized. Too large for a sprint. MUST be split before committing.

Reference Story Set:
┌──────────┬──────────────────────────────────────────────────────────┐
│ Points   │ Reference Description                                   │
├──────────┼──────────────────────────────────────────────────────────┤
│ 1        │ Fix a typo in the UI, update a configuration value      │
│ 2        │ Add a new field to an existing form with validation      │
│ 3        │ Create a new API endpoint with standard CRUD operations  │
│ 5        │ Implement a search feature with filtering and sorting    │
│ 8        │ Build a multi-step wizard with validation and state mgmt │
│ 13       │ Integrate with a third-party payment gateway             │
│ 21       │ Build a real-time notification system from scratch       │
└──────────┴──────────────────────────────────────────────────────────┘

1. Product Owner presents a user story and answers questions (5 min max)
2. Each team member privately selects a card (Fibonacci: 1, 2, 3, 5, 8, 13, 21)
3. All cards revealed simultaneously
4. If consensus: record the estimate and move on
5. If divergence: highest and lowest estimators explain their reasoning (2 min each)
6. Re-vote (usually converges in 2 rounds)
7. If still no consensus after 3 rounds: use the higher estimate or mark for further refinement

Scenario: Large spread (2 vs 13)
Action: The 2-estimator often underestimates unknowns. The 13-estimator often
        has domain knowledge the others lack. Discuss what each knows that
        the other might not.

Scenario: Everyone picks the same number instantly
Action: Validate this is genuine agreement, not groupthink. Ask "Did anyone
        consider [alternative approach]?"

Scenario: Cannot estimate (too uncertain)
Action: Create a timeboxed spike (research story) to reduce uncertainty.
        Estimate the spike, not the original story.

Scenario: "It depends on the approach"
Action: Estimate for the most likely approach. Note assumptions. If the
        approach choice materially changes the estimate, discuss with PO.

XS - Less than a day of work. Trivial change.
S  - 1-2 days. Small, well-understood change.
M  - 3-5 days. Moderate complexity, some unknowns.
L  - 1-2 weeks. Significant effort, multiple components.
XL - 2-4 weeks. Large feature, cross-cutting concerns. Should be split.
XXL - More than a month. Epic-level. Must be decomposed before work begins.

XS → 1-2 points
S  → 2-3 points
M  → 5 points
L  → 8-13 points
XL → 13-21 points
XXL → Must split

1. Lay out all stories/epics on a table or digital board
2. Silently, team members place each story in a size column (XS through XL)
3. Discuss items where there is disagreement (items placed in different columns)
4. Reach consensus and record sizes
5. Duration: 30-50 stories in about 1 hour

Sprint 1: 28 points completed
Sprint 2: 32 points completed
Sprint 3: 25 points completed (holiday week)
Sprint 4: 35 points completed
Sprint 5: 30 points completed

Average Velocity: (28+32+25+35+30) / 5 = 30 points/sprint
Rolling Average (last 3): (25+35+30) / 3 = 30 points/sprint
Range: [25, 35]

Remaining backlog: 200 story points

Optimistic (using highest velocity):
  200 / 35 = 5.7 sprints ≈ 6 sprints (12 weeks)

Most Likely (using average velocity):
  200 / 30 = 6.7 sprints ≈ 7 sprints (14 weeks)

Pessimistic (using lowest velocity):
  200 / 25 = 8.0 sprints = 8 sprints (16 weeks)

Forecast: 12-16 weeks, most likely ~14 weeks

Factor                          │ Adjustment
────────────────────────────────┼──────────────
Team member leaving             │ Reduce proportionally minus 10% for knowledge transfer
New team member joining         │ Reduce by 20% for first 2 sprints (onboarding drag)
Holiday/vacation sprint         │ Reduce proportionally to available days
New technology/domain           │ Reduce by 30-50% for first 2-3 sprints
Technical debt payment sprint   │ Reduce feature velocity by 20-40%
Major refactoring               │ Reduce by 40-60% during refactoring sprints

1. Collect historical velocity data (at least 8-10 sprints)
2. For each simulation run:
   a. Randomly pick a velocity from historical data
   b. Subtract from remaining work
   c. Repeat until remaining work ≤ 0
   d. Record number of sprints needed
3. Run 10,000 simulations
4. Report percentiles:
   - 50th percentile: "There is a 50% chance we finish by sprint X"
   - 85th percentile: "There is an 85% chance we finish by sprint Y"
   - 95th percentile: "There is a 95% chance we finish by sprint Z"

Simulation Results (10,000 runs):
┌────────────┬─────────┬────────────┐
│ Percentile │ Sprints │ Date       │
├────────────┼─────────┼────────────┤
│ 50%        │ 7       │ July 15    │
│ 70%        │ 8       │ Aug 12     │
│ 85%        │ 9       │ Sep 9      │
│ 95%        │ 11      │ Nov 4      │
└────────────┴─────────┴────────────┘

Recommendation: Commit to the 85th percentile date (Sep 9).
Communicate 50th percentile as "target" and 85th as "commitment."

┌─────────────────────┬───────────┬───────────┬────────────┬──────────────┐
│ Technique           │ Speed     │ Accuracy  │ Best For   │ Team Size    │
├─────────────────────┼───────────┼───────────┼────────────┼──────────────┤
│ Planning Poker      │ Medium    │ High      │ Sprint     │ 3-9          │
│ T-Shirt Sizing      │ Fast      │ Low-Med   │ Roadmap    │ Any          │
│ Affinity Estimation │ Very Fast │ Low-Med   │ Large batch│ Any          │
│ Three-Point         │ Slow      │ High      │ Critical   │ 1-3 experts  │
│ #NoEstimates        │ Fastest   │ Low       │ Mature     │ Experienced  │
│ Monte Carlo         │ N/A       │ Highest   │ Forecast   │ N/A (data)   │
└─────────────────────┴───────────┴───────────┴────────────┴──────────────┘

For high-stakes items requiring higher precision:

O = Optimistic estimate (best case, everything goes right)
M = Most Likely estimate (normal conditions)
P = Pessimistic estimate (worst case, many things go wrong)

PERT Estimate = (O + 4M + P) / 6
Standard Deviation = (P - O) / 6
Confidence Range = PERT ± 2 * StdDev (covers ~95% of outcomes)

Example:
O = 3 days, M = 5 days, P = 15 days
PERT = (3 + 20 + 15) / 6 = 6.3 days
StdDev = (15 - 3) / 6 = 2.0 days
95% Range = 6.3 ± 4.0 = 2.3 to 10.3 days

Instead of estimating individual stories:
1. Track throughput: stories completed per sprint
2. Forecast using throughput: "We complete 8-12 stories per sprint"
3. Count remaining stories: "45 stories left"
4. Forecast: "45 / 10 (avg) = 4.5 sprints"
5. Communicate range: "4-6 sprints (roughly 8-12 weeks)"

Project Phase          │ Estimate Accuracy Range
───────────────────────┼────────────────────────
Initial concept        │ 0.25x to 4x (16x range)
Approved product def   │ 0.5x to 2x (4x range)
Requirements complete  │ 0.67x to 1.5x (2.25x range)
UI design complete     │ 0.8x to 1.25x (1.56x range)
Detailed design        │ 0.9x to 1.1x (1.21x range)

"Based on our current velocity and remaining scope, we have an 85% confidence
level of delivering by [date]. Our best case is [earlier date] and our worst
case is [later date]. The primary risks to this forecast are [list top 2-3 risks]."

"Remaining scope: [X] story points
Current velocity: [Y-Z] points per sprint (range of last 5 sprints)
Forecast: [A-B] sprints remaining
Key assumptions: [list assumptions]
Risks that could extend the timeline:
  - [Risk 1]: +[N] sprints if it materializes
  - [Risk 2]: +[N] sprints if it materializes"

"We estimated this as a [X]. Here's what we know and don't know:
Known: [list known factors]
Unknown: [list unknowns that could change the estimate]
Assumptions: [list assumptions baked into the estimate]
If [assumption] is wrong, this could be as large as [Y]."

High Confidence (>80%):
- Team has done similar work before
- Requirements are clear and stable
- Technology is familiar
- No external dependencies

Medium Confidence (50-80%):
- Some unknowns exist but are bounded
- Requirements are mostly clear
- Minor technology learning needed
- External dependencies are manageable

Low Confidence (<50%):
- Significant unknowns
- Requirements are evolving
- New technology or domain
- Complex external dependencies
→ Consider a spike before committing