Photo by tom balabaud from Pexels

Make the Product Backlog DEEP

Published on 8th February 2010 Last Updated on: June 24, 2021

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.

Appropriately detailed product backlog


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.

Post a Comment or Ask a Question

1 Comment

  • Change Management says:

    You made some good points there. I did a search on the topic and found most people will agree with your blog.

14 Trackbacks

  • 4 Akronyme für Scrum | Uli Armbruster says:

    […] Deep […]

  • Tips to Grooming the Product Backlog Effectively says:

    […] Grooming should result in a DEEP  product backlog […]

  • Better Agile Planning with Projected Iterations - Agile Bench says:

    […] see a lot of deep backlogs. Teams that practice agile planning usually have a well groomed backlog towards the top […]

  • Making the Product Backlog DEEP « The IT Blog says:

    […] Roman Pichler Rate this: Like this:LikeBe the first to like this post. Posted by PE in Agile, Requirements, […]

  • agile42 | Tips and Tricks for the beginner Product Owner says:

    […] little pieces. It does mean to keep the Product Backlog „detailed appropriately“ (see DEEP acronym). So keep your top requirements sliced into small pieces and wait with slicing the rest until it is […]

  • The Product Owner and the start of a Backlog « Inevitably Agile says:

    […] backlog should be D.E.E.P (some more info on […]

  • Product Management in an Agile style « The Cognidox Blog says:

    […] Roman re-iterated an idea (from Mike Cohn) that the product backlog would ideally be DEEP: It should be detailed appropriately, estimated, emergent, and prioritized. More on that from his blog. […]

  • Alternde Product Backlog Items – Vermeiden Sie Karteileichen > Agile, Product Backlog, Scrum > Startup, Start-Up, Internetunternehmen, Webunternehmen, Gründer, Website, Webplattform, Webshop, E-Commerce, Internetindustrie, Venturecapital says:

    […] allgemein zur aktuellen (Projekt-) Situation getätigt werden. Roman Pichler spricht vom “DEEP Backlog” und wie viele andere Scrum-Experten rät auch er zum regelmäßigen “grooming” […]

  • Roman’s Top Ten Product Backlog Tips » All Things Product Owner - Roman Pichler's Thoughts on Agile Product Management and Product Ownership says:

    […] your product backlog DEEP. Ensure that is is detailed appropriately, emergent, estimated, and […]

  • From Idea to Launch » All Things Product Owner - Roman Pichler's Thoughts on Agile Product Management and Product Ownership says:

    […] recommends in his book Agile Project Management with Scrum that a product vision and an initial product backlog should be available before the first sprint starts. Applying this advice results in the following […]

  • The Product Owner and the start of a Backlog says:

    […] backlog should be D.E.E.P (some more info on […]

  • Change Management says:

    You made some good points there. I did a search on the topic and found most people will agree with your blog.

  • What is Agile Product Management? « All Things Product Owner - Roman Pichler's Thoughts on Agile Product Management and Product Ownership says:

    […] emerge. There is no definition phase and no market or product requirements specification. The product backlog evolves based on customer and user […]

  • What is Agile Product Management? « All Things Product Owner - Roman Pichler's Thoughts on Agile Product Management and Product Ownership says:

    […] emerge. There is no definition phase and no market or product requirements specification. The product backlog evolves based on customer and user […]

  • Synesthesia says:

    […] Making the Product Backlog DEEP […]

Leave a Reply to From Idea to Launch » All Things Product Owner - Roman Pichler's Thoughts on Agile Product Management and Product Ownership Cancel reply

Your email address will not be published. Required fields are marked *