Relative Size Estimating—It’s Just an Exercise in Binning!

Agile teams that decide they want to estimate the size of their product backlog items may employ a technique like Planning Poker®. Planning Poker helps team members better understand product backlog items (often user stories) and reach consensus on the relative sizes of these items.

Relative-size-estimation techniques typically use a fixed scale or sequence of numbers. When applying Planning Poker many people use a modified version of the Fibonacci sequence (½, 1, 2, 3, 5, 8, 13, 20, ...); others use the Power of 2 (1, 2, 4, 8, 16, 32, ...). These scales aid agile estimation in two key ways.

First, both of these scales have more numbers at the bottom of the range and fewer, more widely spaced numbers at the top. The smaller numbers remind us to keep most of our product backlog items small. Wide spacing of numbers further out reinforces the point that we have far less precision with large items.

Second, neither scale has every possible number, forcing estimators to find the “best fit” or “best matching” number to use. This “best fit” estimation is a form of binning, a technique that helps us accelerate our estimation speed and also helps us avoid the temptation to try to obtain more precise estimates than is possible.

What is Binning?

An analogy will help illustrate binning. Let’s say we work at the post office and we need to group packages of similar size together in the same bin (see the figure below).

Relative Size Estimating is a Form of Binning

For each new package we receive, we have to decide which bin is the best fit. Let’s say we are handed a new package to sort. At a glance, we can tell that it is much bigger than anything in the 1 bin; and it’s clearly smaller than anything in the 5 bin. After a bit more consideration, we determine that it is also bigger than packages in the 2 bin. It looks most similar to packages in the 3 bin, so we place it in the 3 bin.

It is important to realize that not all packages in the same bin will be of identical size; some have different shapes, lengths, and weights. However, in aggregate all packages in the same bin fall within a given small interval whose mid-point value is represented by the bin number.

Many Comparison Points Make Light Work

The good news is that relative size estimation gets quicker the more we do it. The more packages we have in the bins, the easier it becomes to size and bin future packages because we’ll have more points of comparison.

At the same time, we don’t want to get bogged down by our choices and force a level of precision we simply don’t have. By fixing the numbers of the scale (not permitting a bin of every size), we force people to approximate and choose the best bin to put the package in, even if it might not be a perfect fit.

The same is true with our product backlog items. We use specialized scales to help us sort through the items, compare them to other items that have already been estimated, and quickly decide, “Does this more closely match the other 3s or the other 5s?” Estimating product backlog items doesn't need to be any more complicated or precise than that.

By the way, the binning image shown above is part of the Visual AGILExicon® that I created for my classroom presentations and to use in my Essential Scrum book. At no cost you can get hi-res copies of this picture and all of the other pictures in the Visual AGILExicon. For more on agile estimation and velocity, see Chapter 7 of Essential Scrum.