Comparing Big Items with Small Ones

How big is that building? How big is that city? You could estimate both in terms of the number of people they could hold. If you estimated the capacity of all the buildings in the city and added them up, you’ll get quite a different answer than your direct estimate for the city. In part, that’s because the capacity for cities and buildings have somewhat different meanings, and partly because we think of cities and buildings differently, which is reflected in our estimates.

Frequently, I see people trying to estimate large chunks of vaguely defined functionality, epics or features, using an extension of the same scale they use to estimate small slices of more explicitly defined User Stories. They may use the numbers 1, 2, 3, 5, 8, 13, 20 for the small slices and 100, 200, 300, 500, 800, 1300, 2000 for the large chunks to keep them separate. The temptation is great to perform simple arithmetic to group a number of small slices into one large chunk, or break a large one into a number of small slices. There are even agile project management tools that do this automatically, with no way to override it. This hides the uncertainty in your estimates and story slicing.

Life is not that simple. If you do this, you will surely fool yourself. Estimate stories of different granularity separately. Use different scales so others don’t get confused. For large items, you might use T-shirt sizes—small, medium, large, extra-large. Or use something unusual to emphasize the imprecision. I’ve heard of using animals—rat, cat, dog, pig, cow. The astute reader will notice that, in unusual cases, there are overlaps in the sizes of these animal categories. You’re likely to find similar overlap in your story sizes. Certainly no one will assume that two cats equals one dog.

How many explicitly defined slices fit into one dog? That’s an estimate. You can decompose the dog-sized chunk of work and count the smaller pieces. Or, if you prefer, you can estimate the smaller pieces and add up those estimates. Either of those is a starting point.

When you implement those smaller pieces, you get a chance to see what you got wrong. Some people like to compare estimates to actuals. If you do that, there’s a temptation to relate the small scale to the large scale using these actuals instead of the estimates. Resist that temptation. At the times you need the relation between items on the small scale and items on the large scale, you’ll only have estimates available.

You can, however, check the aggregate time for all the smaller pieces to get one data point on how long a dog-sized chunk of work takes. And, if you pay attention as you go, you can count up all the small slices that were discovered while you implemented the functionality. This gives you a feel for how much work is still invisible when you’re considering future large chunks of work.