31days until

Granularity Gradient

... 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 log 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 commitment 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. 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. This is why 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.

Therefore: Break down the earliest PBIs into Small Items To Estimate of  half a sprint or less of work for an individual, the later ones may be epics, with the in-between ones broken down in accordance with how distant their release date is. Items near the top of the Product Backlog should be broken down into PBIs whose effort is no longer than half a sprint for a single individual. Even if emergent requirements cause the estimate to double during the sprint, the team can still deliver the PBI.

✥      ✥      ✥

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. Scrum 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.

Author: Jim Coplien