Estimation in XP

Humans are bad at estimating absolute time. "This will take 3 days" is almost always wrong. We underestimate complexity and overestimate our productivity.

But humans are good at relative comparison. "This story is about twice as big as that one" is something we can do reliably.

XP uses relative estimation. Instead of estimating hours, we estimate size. A story might be a "2" or a "5" or a "13." These numbers don't mean hours or days—they mean relative size compared to other stories.

Why relative works:

• We're comparing things we understand (story to story, not story to time)
• It's faster (you don't need detailed task breakdowns)
• It's more honest (no false precision)
• It self-corrects through velocity tracking

Story points are the most common unit for relative estimation.

Points represent effort, complexity, and uncertainty combined—not time. A 5-point story is roughly twice the effort of a 2-point story (ish), but not necessarily twice the hours.

Common point scales:

• Fibonacci: 1, 2, 3, 5, 8, 13, 21, ? (gaps force you to choose)
• Powers of 2: 1, 2, 4, 8, 16 (simple doubling)
• T-shirt sizes: XS, S, M, L, XL (non-numeric, good for high-level planning)

Tips for pointing stories:

• Compare to reference stories ("Is this bigger or smaller than Story X?")
• Don't overthink it (points are fuzzy by design)
• Include uncertainty in the estimate (unknown = bigger)
• Re-estimate if you learn something that changes your understanding

Planning poker is a technique for reaching team consensus on estimates.

How it works:

1. The product owner reads a story
2. Team members ask clarifying questions
3. Everyone privately selects an estimate card
4. All cards are revealed simultaneously
5. Highest and lowest estimators explain their reasoning
6. The team discusses and re-votes if needed
7. Consensus emerges (or the average is taken)

Why simultaneous reveal? To prevent anchoring. If the senior developer says "5" first, everyone else adjusts toward 5. Revealing simultaneously captures independent opinions.

Why discuss outliers? The person who said "13" might know something others don't ("this requires database migration"). The person who said "2" might have a simpler approach. Both views improve the estimate.

Planning poker is as much about building shared understanding as getting a number. The discussion surfaces assumptions, risks, and design decisions.

Velocity is how many points the team completes per iteration. It's the key to turning relative estimates into predictions.

If the team completed 30 points last iteration, they'll probably complete about 30 points next iteration. This is called yesterday's weather—the best predictor of tomorrow's weather is today's weather.

Using velocity:

• If you have 100 points of work and a velocity of 20, expect about 5 iterations
• If the customer wants to ship in 3 iterations, you can do about 60 points of work
• Velocity fluctuates; use a rolling average (last 3-5 iterations)

What affects velocity:

• Team composition (vacations, new members)
• Technical environment (new framework, infrastructure changes)
• Work type (new feature vs bug fixes)
• Team focus (interruptions kill velocity)

Don't game velocity. It's not a productivity metric—it's a planning tool. Inflating points or cutting corners to "increase velocity" defeats the purpose.

Estimates are guesses. They will be wrong. XP acknowledges this and builds in adaptability.

Common estimation failures:

• Unknown unknowns: Unforeseen complexity emerges
• Dependencies: External teams or systems cause delays
• Scope creep: The story grows as you build it
• Technical debt: Existing code is harder to change than expected

What to do when off-track:

1. Surface it immediately (transparency)
2. Re-estimate based on new understanding
3. Discuss with the product owner
4. Negotiate scope if needed (smaller increment, defer features)

Don't hide it. Don't work overtime to hit a bad estimate. The whole point of estimation is to plan—if the plan is wrong, change it.

Over time, estimates improve. As the team gains experience with the codebase and each other, uncertainty decreases. But they'll never be perfect—that's why XP emphasizes adaptation over prediction.