Pattern of the Month: Relative Sizing
Pattern of the Month: Relative Sizing
For the pattern of the month, Ian Mitchell elaborates on relative sizing and also gives us an amazing definition in the video at the bottom!
Join the DZone community and get the full member experience.Join For Free
A chap in Backlog Refining
Just couldn't get relative sizing
We asked "are you sober?"
When he said, in Planning Poker
"My 8's twice as big as your 5 thing"
In time-boxed approaches to agile delivery such as Scrum, fairly substantial pieces of work can be taken on that represent up to a month of team effort for as many as 8 or 9 developers. Although the size of the batch is thus limited, along with the risk, it still represents a significant investment for which a degree of planning is needed. Fundamental to the plan is the need to estimate how much the team can reasonably expect to take on, and to this end, each item in the backlog of work is typically allocated a rough size. The proposed forecast of work can then be summed, and adjusted if it is thought to be too large or too small.
It's tempting for teams to estimate items in terms of absolute values, such as days and hours, or dollars and cents: "This item will take a day and cost X; this one will take a couple of hours and cost Y". However, estimates are just that....estimates. Absolute measures such as time and money can seem to be very precise but, when used in an estimate, they are very difficult to employ accurately. The precision is false, any accuracy implied is without foundation, and attempts to improve the quality of the forecast is more likely to prove wasteful than it is to increase reliability and productivity.
What's more, development teams are not expected to be accountants. Rather, they are expected to deliver value in the form of usable increments of working product. Estimation should be fit for this purpose and this means that the form estimates take is, strictly speaking, quite irrelevant. If a team is funded for a time-box of a certain number of weeks, and if they deliver value at the end of it, then the method they use for sizing the work they undertake becomes immaterial.
"Relative Sizing" is an approach which deliberately eschews false precision in estimation. Instead, it is merely asserted that "this item is smaller than that", or "about three times as large" as something else, or perhaps "a lot bigger" than other items in the backlog. Numbers can still be used to gauge these items, but their value is not anchored in terms of time or money but rather in terms of their relative effort and complexity.
Story Pointing is a good example of this technique, and it is the most common approach to relative sizing in agile practice. The numbers have no intrinsic value, and since it is generally easier to estimate smaller values with greater accuracy than large ones, the Fibonacci sequence is roughly emulated. Each item is thus estimated to have a relative value of 1, 2, 3, 5, 8, 13, or 20, and so on. If a team can establish a budget for the time-box, such as 40 points, then the body of work that is forecast for completion can be adjusted to fit.
However, there is a problem with story pointing...it's still based on numbers. This can encourage novice teams to view points quantitively, and to map or correlate them to measures with which they are more familiar, such as hours or days. This prejudice must be eliminated if false precision is to be avoided and the pure relative sizing of estimates achieved.
T-Shirt Sizing is an alternative technique which can avoid this problem. Instead of numbers, more qualitative values such as Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL), and Extra Extra Large (XXL) are used instead. During estimation, team members collaborate to organize proposed items under the headings XS to XXL. If desired, story points can then be allocated by mapping each T-Shirt size to a value post-facto. This allows metrics to be gathered about the flow of work and used to populate a velocity or burndown chart.
"Relative Sizing" is Pattern of the Month at agilepatterns.org.
Intent: Allow a backlog to be ordered when it is difficult for team members to estimate the size of each item in a backlog
Acorns compare their height with each other
Everything is relative
Also Known As:
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.
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.
Applicability: Relative sizing is useful when teams are unable or unwilling to create time-based estimates.
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.
Relative Estimation, Agile Alliance
How Can We Get the Best Estimates of Story Size?, by Mike Cohn
Agile Estimation in Practice, The Agile Zone
Opinions expressed by DZone contributors are their own.