Relative vs absolute estimation (and why relative wins)

People are bad at 'how long will this take' and good at 'is this bigger than that.' Relative estimation uses the second — and it's why story points work.

People are bad at “how long will this take.” They’re good at “is this bigger than the one you already shipped.” Relative estimation uses the second question, and that’s the whole trick.

Absolute estimation asks for a duration — and humans are predictably bad at it. We round optimistically, miss the compounding work, and forget the hidden parts. Relative estimation asks for a comparison instead, and we’re surprisingly good at that: we can see sizes side by side without committing to any single number of hours.

Why relative estimation works

Planning poker exploits the asymmetry. The reference story is the team’s anchor, and new work gets sized against it — bigger, smaller, much bigger, about the same. The points scale isn’t a duration scale; it’s a spread-of-comparison scale. That’s why the gaps are non-uniform: the precision is real for small sizes and gets deliberately fuzzier for large ones, because that’s how confidence actually behaves.

The property that falls out of this is stability. Because a relative estimate is tied to the work rather than to a person’s speed, it holds up when the team composition changes — the size of the story is the same whoever picks it up. The team’s rate of delivering those sizes is what varies, and that’s exactly what velocity is there to track.

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; a per-story hour estimate gives you a date that pretends the noise doesn’t exist, which is the conversion trap in another costume. For the capacity side of that same translation, see velocity and capacity planning.

Affinity estimation: relative at scale

For a backlog-wide first pass, affinity estimation is relative estimation done in bulk: drag stories into size groups by comparison, no cards involved. It’s faster than planning poker and fuzzier in output, which makes it a good pre-refinement pass before the team sizes the near-term work properly. It’s one of several estimation techniques that lean on comparison rather than the clock.

Frequently asked questions

What is the difference between relative and absolute estimation in agile?

Absolute estimation assigns a specific duration to a task — hours or days. Relative estimation compares a task to others and sizes it on an abstract scale like story points, without committing to a duration. Relative sizing is faster and holds up better, because people judge comparison well and absolute time badly.

What is relative estimation in agile?

Relative estimation sizes a piece of work by comparing it to a reference story the team has already delivered — bigger, smaller, about the same — instead of predicting how many hours it will take. Story points and planning poker are the common way teams do it.

Why is relative estimation better than estimating in hours?

Because people are unreliable at absolute time and surprisingly good at comparison. Relative estimation avoids anchoring on the loudest voice and the seniority bias hour estimates invite, and — through velocity — still produces a date when someone needs one.