Relative Estimation: The Idea Behind Every Agile Technique

Relative estimation sizes work by comparing it to other work - "is this bigger or smaller than X?" - instead of predicting how long it will take in hours or days. Every technique in the complete agile estimation guide - Scrum Poker, t-shirt sizing, affinity estimation - is a structured way of producing that comparison as a group. This page covers the idea itself: why it works, where it breaks down, and a worked example that doesn't require any software background to follow.

The core idea, without any software in it

Imagine sizing three tasks: hang a picture, install a door, build a house. Nobody needs construction experience to rank them by effort - picture, door, house, in that order, with growing gaps between them. Most people could also say the gap between "door" and "house" is much bigger than the gap between "picture" and "door," even without knowing exactly how many hours either job takes.

That ranking - reliable, fast, requiring no domain expertise beyond common sense - is relative estimation. Software teams do the same thing with backlog items: "is this story bigger or smaller than the login form we built last sprint?" is a question most team members can answer confidently, even when "how many hours will this take?" produces wildly different guesses from the same people.

Why relative comparisons beat absolute guesses

This isn't a preference - it's a documented human limitation. People are consistently bad at predicting absolute durations for unfamiliar work, but consistently good at comparisons. The research behind this (much of it from Magne Jørgensen and colleagues studying software estimation specifically) shows the same pattern across domains: ask someone "how long will this take" and you get an overconfident, anchored guess; ask "is this bigger than that" and you get a much more reliable answer.

The picture/door/house example makes this intuitive: ask someone to estimate hours for building a house from scratch, with no construction background, and the number is close to meaningless. Ask the same person whether a house takes longer to build than a door, and they'll get it right every time, instantly.

How this becomes a team technique

A single person's relative judgment is useful; a team's shared relative judgment, reconciled through brief discussion, is more reliable still. This is the actual mechanism behind Scrum Poker: each person votes their own relative-size judgment privately, the reveal shows where those judgments diverge, and the ensuing discussion surfaces exactly why one person's comparison differs from another's - often because one person knows something about the work the others don't.

Different techniques use different scales for the same underlying comparison:

• Fibonacci points (0, 1, 2, 3, 5, 8, 13, 21) - numeric, sums into a velocity figure. See story points.
• T-shirt sizes (XS-XXL) - categorical, faster, doesn't sum without a mapping. See t-shirt sizing.
• Affinity grouping - purely spatial/visual, no numbers at all until a later mapping step. See affinity estimation.

All three are relative estimation wearing different clothes. The choice between them is about speed, precision, and audience - not about which one is "more correct," because none of them claims to predict absolute duration in the first place.

A worked comparison, several ways

Take three backlog items: add a tooltip, add a search filter, rebuild the checkout flow.

• Relative ranking alone: tooltip < search filter < checkout rebuild. Obvious to almost anyone on the team, technical or not.
• Fibonacci points: tooltip = 1, search filter = 3, checkout rebuild = 13. The team has now also expressed how much bigger, not just the order.
• T-shirt sizes: tooltip = XS, search filter = S, checkout rebuild = XL. Faster to agree on than exact points, less precise about the gap size.

Every version encodes the same underlying relative judgment. What changes is precision and speed, not the fundamental comparison being made.

Where relative estimation breaks down

When there's nothing to compare against yet. A brand-new team with no completed stories has no reference point - the first few relative estimates are closer to arbitrary than calibrated, because "bigger or smaller than what?" has no good answer yet. This is why new teams take a few sprints to calibrate before their points mean much.

When a stakeholder needs an actual date, not a ranking. Relative estimation tells you order and rough magnitude, not a calendar. Converting a relative estimate into a schedule requires an extra step - usually velocity (points completed per sprint, historically) or, for a single large estimate, three-point estimation, which is deliberately absolute rather than relative.

When teams compare across each other. Relative estimates are calibrated to one team's own reference points - "our 5" and "their 5" describe different amounts of work, because the comparison set is different. Story points don't transfer between teams for exactly this reason.

Put it into practice

The fastest way to feel why relative comparisons work is to run a real session. Create a free room, pick five stories from an actual backlog, and notice how much faster the team converges on "is this bigger than that" than it would on "how many hours, exactly."