Make the Product Backlog DEEP

Going DEEP

Imagine your boss telling you: “Congratulations, we’d like to ask you to take on the product owner role for our new product! And we’ve done some upfront work for you: Here is the initial product backlog.” You thank her and walk back to your desk, where you look at the backlog and discover that it contains several hundred items. “That’s a big product backlog,” you think and “where should I start?”

This little story illustrates a common challenge: Product backlogs are often too long and detailed, and therefore difficult to use. Part of the solution is to ensure that your product backlog is DEEP: It should be detailed appropriately, estimated, emergent, and prioritized. I find that particularly the first and the third property are often overlooked. (Additional, I recommend that you complement your backlog with a product roadmap and focus the product backlog on the next major release, as I discuss in my post The Product Roadmap and the Product Backlog.)

Detailed Appropriately

The product backlog items are detailed appropriately if higher-priority items are described in more detail than lower-priority ones. “The lower the priority, the less detail, until you can barely make out the backlog item,” write Ken Schwaber and Mike Beedle in their book Agile Software Development with Scrum. Following this guideline keeps the backlog concise and ensures that the items likely to be implemented in the next sprint are ready.

Estimated

The product backlog items–certainly the ones participating in the next major release–should be estimated. The estimates are coarse-grained and often expressed in story points or ideal days. Knowing the rough size of the items helps prioritise them and track the progress of the release.

Emergent

The product backlog has an organic quality: it evolves and its contents change frequently. New items emerge based on customer and user feedback and are added to the backlog. Existing items are modified, reprioritized, refined, or removed on a regular basis.

Prioritised

All items in the product backlog are prioritised (or ordered). The most important and highest-priority items are implemented first. They can be found at the top of the product backlog, as illustrated in the figure above. Once an item is done, it is removed from the product backlog. Note that the Scrum framework does not suggest any prioritisation factors. But I recommend that you first prioritise your backlog by risk. Once the key risks have been addressed, use cost-benefit and dependencies to determine the order in which the items should be implemented.

Groom It!

To ensure that the product backlog is DEEP and stays that way, you have to regularly groom or refine it. Grooming the product backlog is an ongoing, collaborative process that involves the product owner and team, as I describe in more detail in the post Grooming the Product Backlog

To conclude the story from the beginning of this post, my preferred course of action as the designated product owner is to explain to the boss that the product backlog is too detailed and long, which makes it difficult to evolve based on customer and user feedback. This in turn reduces the likelihood of delivering a successful product. The product backlog resembles a disguised requirements specifications, which is a common trap to fall into. My suggestion is use the product roadmap to derive a new product backlog that fulfils the DEEP criteria and to discard the old one–even if that’s not necessarily what the boss wants to hear.