Relative vs absolute estimation

Absolute estimation asks "how long will this take?" — and humans are predictably bad at that question. We round optimistically, miss compounding work, and forget the hidden parts. Relative estimation asks "is this bigger or smaller than the one you already shipped?" — and we're surprisingly good at that. We can see sizes side-by-side without committing to any single duration.

Planning Poker exploits the asymmetry. The reference story is the team's anchor. New stories get sized against it: bigger, smaller, much bigger, similar. The points scale isn't a duration scale; it's a spread-of-comparison scale. That's why the gaps are non-uniform (Fibonacci) — it acknowledges that the precision is real for small sizes and gets fuzzier for large ones.

Why teams reach for absolute anyway

Stakeholders ask "when will it be done." That's an absolute question, and the team feels obliged to answer in absolute units. The right move is to translate at the team level — through velocity, not through per-story duration estimates. Velocity gives you a date with the team's noise built in; per-story duration estimates pretend the noise doesn't exist.

Affinity estimation: relative at scale

For backlog-wide first passes, affinity estimation is relative estimation done in bulk: drag stories into size groups by comparison, no cards involved. Faster than Planning Poker, fuzzier output. Works well as a pre-refinement pass.

See: other techniques for the full menu; how many points per sprint for the velocity story.