Applicability: Relative sizing is useful when teams are unable or unwilling to create time-based estimates.
Structure: A backlog consists of an ordered list of items. Each item has a size. The size will be expressed in relative terms. These terms may be descriptive, such as small, medium or large. Arbitrary numbers that do not reflect any particular unit of measure can be mapped to the terms being used. Items are compared to each other; i.e. this is bigger than that, or smaller, or roughly the same size, and are thereby given a size in the scheme.
Intent: Allow a backlog to be ordered when it is difficult for team members to estimate the size of each item in a backlog
Proverbs:
Acorns compare their height with each other
Everything is relative
Also Known As:
Relative ordering
Motivation: Time-based estimates are unreliable, and are apt to become even more so at larger magnitudes. A way to size backlog items is needed that is independent of time or other absolute measures.
Consequences: Relative sizing can be a difficult concept for teams to understand, as there is no time-based unit of measure. “Relative effort” is often the best way of explaining how items should be compared. Understanding how to size using arbitrary numbers often proves difficult, as there is a common prejudice towards mapping numbers to hours or days. For this reason it is often best to use descriptive terms alone (e.g. small, medium, large).
Implementation: T-shirt sizing uses Extra Small, Small, Medium, Large, Extra Large, and Extra Extra Large as relative sizes. Items may be written as index cards and sorted by the team by placing each one below the most appropriate sized heading. Estimation Poker uses playing cards with sizes on a near-Fibonacci sequence (e.g. 1, 2, 3, 5, 8, 13). Cards are played by each team member when jointly estimating an item; the cards are turned over to expose their values and any significant discrepancies can be reviewed by the group and challenged.
See Also:
Relative Estimation, Agile Alliance
How Can We Get the Best Estimates of Story Size?, by Mike Cohn
Agile Estimation in Practice, The Agile Zone