Make the Product Backlog DEEP

Roman Pichler, author of "Agile Product Management with Scrum: Creating Products That Customers Love" and I use the acronym DEEP to summarize key attributes of a good product backlog:

- **Detailed Appropriately.** If “detailed appropriately” is the tricky part, the [**Product Backlog Refinement Guide**](https://www.mountaingoatsoftware.com/agile/product-backlog/refinement) explains what “enough” looks like and when to stop refining.

User stories on the product backlog that will be done soon need to be sufficiently well understood that they can be completed in the coming sprint. Stories that will not be developed for awhile should be described with less detail.

Estimated. The product backlog is more than a list of all work to be done; it is also a useful planning tool. Because items further down the backlog are not as well understood (yet), the estimates associated with them will be less precise than estimates given items at the top.
Emergent. A product backlog is not static. It will change over time. As more is learned, user stories on the product backlog will be added, removed, or reprioritized.
Prioritized. The product backlog should be sorted with the most valuable items at the top and the least valuable at the bottom. By always working in priority order, the team is able to maximize the value of the product or system being developed.

Product backlogs are discussed in much more detail in Succeeding with Agile.

Last updated October 10th, 2024