Granularity Gradient

In the primordial pattern literature, Christopher Alexander recommends a granularity gradient for the size of windows along the story levels of a house. [1]

... the Product Owner has laid out a release vision as a Product Backlog, taking into consideration the market value of each item and on how much the Development Team believes it will cost to develop the item.

✥       ✥       ✥ 

Small Items are easiest to estimate, but breaking down work items is a lot of work in itself. The work estimates for small product increments and tasks have less error than for larger ones for three reasons. 1. The magnitude of the work (and therefore of the possible error) is smaller than for a larger one. 2. Smaller deliverables and tasks are better understood than larger ones. 3. The percentage error on smaller deliverables and tasks is less than for large ones because there is less of an element of guessing.

If you have a Product Backlog whose items aren’t broken down, the estimates will be coarse and imprecise. It is easy to believe that any estimates are better than no estimates; and that may be true. It is also easy to avoid the discipline of going the extra mile to estimate at a finer level. You can get into analysis paralysis if you spend too much time on estimation. Furthermore, such estimates too easily can be used for micro-management.

It is important to reduce the estimation error as much as possible so the team is confident in meeting its forecast to the Product Owner, and so the Product Owner can meet his or her commitment to the market. It takes work to break down large requirements into small ones. That work takes time, time that is waste in the Value Stream. Furthermore, a Product Backlog with that many items is hard to manage.

For near-term items, the effort spent estimating effort is worth the cost: the market will remember a schedule slip longer than it will remember how much it paid for an item.

However, even the best estimates can be invalidated by emergent requirements: changes in the market, in technology, or team staffing. The longer that time goes on, the higher the likelihood that such changes may emerge. The more distant a PBI is in time, the lower the confidence in the estimate. On the other hand, one can use lead time to one’s advantage: High lead time means more time to reduce the uncertainty that comes with any new product increment idea. Boehm [2] has shown empirically that estimates may be too large or too small by a factor of as much as four until the team is able to detail requirements, and such detailing takes place over time. But because of changes in the market and other factors in the environment, breaking down long-term requirements is not enough and, in general, there is nothing that one can do to estimate long-term requirements with certainty. And just the passage of time isn’t enough [3]: the team must be continuously incorporating new insights they gain into the state of the market, into the team’s own changing level of experience, and into the ongoing changes in the product itself. This is one reason that long-term waterfall development cycles miss the mark. Yet even in the short term, the best of estimates fall victim to emergent requirements. Such requirements may double the number of tasks or overall effort required to meet a market need.

Processing large batch sizes increases the variance in the process. To reduce variance, reduce batch size. [4]

Relatively worthless components of a development increment can easily hide in a larger PBI, but become visible as being less valuable when considered for their own sake after the larger PBI is broken down.


Break down the earliest PBIs into Small Items of half a Sprint or less of work for an individual (about 10% of the total Sprint work) for each one. Later PBIs should be broken down such that their size is proportional to their depth in the backlog. A PBI more than four or five Sprints in the future may be large and little more than a vision of what may be possible. Said another way, no PBI within the top two or three Sprints should take more than 5% or 10% of the total PBI effort for that Sprint. Even if emergent requirements cause the estimate to double during the Sprint, the team can still deliver the PBI.

✥       ✥       ✥ 

Breaking down the Product Backlog this way lays a foundation for a more fully Refined Product Backlog (towards Definition of Ready). Small PBIs and small Sprint Backlog Items both reduce risk by reducing the leakage cost if the team fails to take any single unit of delivery or work to completion. See Small Items.

With a gradient of size, the Product Backlog effectively offers a top-down view of the items that are closer to the bottom and a bottom-up view of those closer to the top. This is in line with the recommendation of [5], which says to “[p]refer top-down estimation in the early (conceptual) phases of a project and switch to bottom-up estimation where specific development tasks and assignments are known.”

Estimate all the PBIs, including the ones for the distant future. Refresh those estimates less frequently than those whose release time is more imminent. Do not waste the effort of breaking them down — it is wasted effort, since the resulting improvement in accuracy will be overshadowed by unplanned changes.

Avoid estimating at a level of granularity that would lead to micro-management. Estimation Points are the preferred method, but even those can be converted to hours. Informal Scrum folklore recommends estimating to the granularity of two hours; in experience, we have found such fine estimates to be self-fulfilling prophecies in complex emergent projects, and estimating to the granularity of about a day is enough.

This is a broadly accepted practice.

[1] Christopher Alexander. Natural Doors and Windows. In A Pattern Language. Oxford, UK: Oxford University Press, 1977, pattern 221.

[2] Barry Boehm. Software Engineering Economics. New York: Prentice-Hall, 1981, p. 311.

[3] Steve McConnell. Software Estimation: Demystifying the black art. Redmond, WA: Microsoft Press, 2006, p. 38.

[4] Don Reinertsen. The Principles of Product Development Flow: Second Generation Lean Product Development. Redondo Beach, CA: Celeritas Publishing, March 29, 2012, p. 112.

[5] Adam Trendowicz and Ross Jeffery. Software Project Effort Estimation. Basel, Switzerland: Springer International Publishing, 2014, p. 143.

Photo credits: The Scrum Pattern Group: Mark den Hollander.