Make the Product Backlog DEEP

The product backlog is intended to be a simple tool. But in reality, product backlogs are often too long, too detailed, and difficult to use. This post explains how you can avoid this common trap by making your backlog DEEP: Detailed appropriately, estimated, emergent, and prioritised.

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 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 focus the product backlog on the next product goal, as I discuss in my article Product Goals in Scrum.

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 necessary to meet the product goal selected—should be estimated. The estimates can be coarse-grained and are often expressed in story points or ideal days. Knowing the rough size of the items helps prioritise them and track the progress of the development effort. Let your development team choose the estimation unit they are most comfortable with. If this turns out to be difficult for the, then the Scrum Master should advise.

Emergent

The product backlog has an organic quality: It evolves and its contents change frequently. New items emerge based on the customer and user feedback you receive and are added to the backlog. Existing items are modified, reprioritised, 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 usually found at the top of the product backlog, as illustrated in the picture 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 product 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.

Regularly Update Your Backlog

To ensure that the product backlog is DEEP and stays that way, you have to regularly update and refine it. Refining the product backlog is an ongoing, collaborative process that involves the product owner and team, as I describe in more detail in the post Refining 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 it based on any user feedback received. 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 recommendation is to discard the product backlog, create a product roadmap, and derive a new backlog from it that fulfils the DEEP criteria, even if that’s not necessarily what the boss might want to hear.