An Overmanaged Product Backlog

I run across a lot of Scrum Teams that are struggling with a lack of detail in their Product Backlogs. To combat this, Developers spend additional time during the Sprint in the Product Backlog adding details, sizing, acceptance criteria, and anything they can to gain a better understanding of the scope of a particular Product Backlog Item. The practice of adding those kinds of details is called Product Backlog refinement.

Quite often, as more time is spent in defining the Product Backlog by Developers, the Product Owner increases the time that they spend adding details to Product Backlog items so that refinement is easier on the Scrum Team. They then meticulously order the Product Backlog considering all of the details they have added and considerations the Developers add.

These Scrum Teams become consumed by having the perfect Product Backlog. This is as problematic as a Product Backlog lacking details -- perhaps even more so.

That’s because more is unknown than known in the complex domain of work. We should consider every Product Backlog item in the Product Backlog as an experiment for production. There is no guarantee that any given item will satisfy a new or existing customer need. Perhaps spending all of that additional time elaborating upon Product Backlog Items is a waste? Let’s look to Evidence-Based Management (EBM) for help.

( Image 1.0 illustrates the non-linear path to achieving goals )

Image 1.0 illustrates the non-linear path towards achieving a strategic goal - a long-term objective often spanning years. It will take many intermediate goals - a mid-term objective - to achieve a strategic goal. Some of those intermediate goals will be very successful experiments, some moderately successful, and some may need to be abandoned. We don’t know until we take small steps, in the form of immediate tactical goals, towards achieving intermediate goals and as we measure along the way. 

Imagine 1.0 illustrates that goals are complex and not a guarantee. So how can a single Product Backlog Item be a guarantee? Why should we spend a lot of time elaborating upon a Product Backlog Item?

The goal structure is supported by the Key Value Areas (KVAs), as illustrated in image 1.1, which we use to provide evidence in the form of measurement. Here are some questions to ponder as you consider Product Backlog Items through the lens of each Key Value Area (KVA):

• Unrealized Value (UV) - Is there a new or current customer need that we are hoping this Product Backlog Item fulfills? Will this close a satisfaction gap?
• Current Value (CV) - Are we going to be adding additional value to a need we are already fulfilling?
• Time-to-Market (T2M) - Will this item help us get value faster to market so that we can test an experiment?
• Ability-to-Innovate (A2I) - Will we be more effective as a Scrum Team after we complete this item? 

Considering the Key Value Areas illustrated through the questions above, the argument could be made that by elaborating upon a Product Backlog Item we are improving a team's Ability-to-Innovate (A2I) and increasing Time-to-Market (T2M). That is not necessarily true. In fact, I would make the argument that adding a large amount of detail to those Product Backlog Items is not guaranteed to help you at all. 

Think about the non-linear path to accomplishing goals. Then consider how it takes many Product Backlog Items to accomplish those goals. Even at the smallest level of goals like Immediate Tactical (or in Scrum a Sprint Goal), we have a large degree of uncertainty in our work. The more time we spend trying to define Product Backlog Items, we may be wasting time building the hypothetical value the Product Backlog Items are meant to define. We are spending time doing analysis that may or may not result in value instead of building. 

Another thing to consider is that if you find that a Product Backlog Item relates to Time-to-Market (T2M) or Ability-to-Innovate (A2I) it doesn’t represent customer value at all. It represents your organizational ability to run experiments. You could argue then, that those Product Backlog Items are not representative of value. Just your capability and speed to deliver the hypothetical value a Product Backlog Item represents.

Overmanaging a Product Backlog can be wasteful. Product Backlog Items are no guarantee of value so details should be added with the minimum amount of detail to perform the work.

Learn more about me by checking out my profile: https://www.scrum.org/todd-miller