The DEEP Product Backlog

Definition

DEEP — an acronym Pichler credits to Mike Cohn — names four qualities a healthy product backlog must have simultaneously. Detailed Appropriately: higher-priority items carry more description; lower-priority ones stay coarse until their priority rises ("the lower the priority, the less detail," quoting Schwaber and Beedle). Estimated: every item carries a coarse-grained size (story points or ideal days) so it can be prioritized and planned. Emergent: the backlog is never finished — items are added, changed, or removed continuously as understanding grows. Prioritized: every item has a rank, with the most important at the top, so "priority" still means something.

In the Book

The book opens the prioritization discussion with an anecdote: a product manager, asked to rank a pile of use cases, replies "I can't. They are all high-priority" — which the book treats as equivalent to having no priorities at all. Four prioritization factors follow. Value: an item is only worth keeping if it's necessary to bring the product to life, argued through Google's launch of Google News — the team could not agree whether to filter by date or location, shipped with neither, and post-launch feedback (300 requests for date filtering versus 3 for location) answered the question the team couldn't resolve by debate. Knowledge, uncertainty, and risk: uncertain, risky items should be pulled forward specifically to generate the knowledge that reduces risk, enabling a deliberate "fail early" posture. Releasability and dependencies round out the factors. The Detailed Appropriately quality is depicted as a triangle (Figure 3.1) narrowing from many fine-grained items at the top of the priority stack to few coarse epics at the bottom.

Why It Matters

Any plan that tries to be fully detailed and fully fixed from the start either wastes effort specifying things that will change, or freezes decisions before enough is known to make them well. Treating a backlog — or any prioritized work list — as continuously evolving, with investment in detail scaled to how soon an item will actually be acted on, avoids both failure modes: over-specification waste on things that may never happen, and under-specification risk on things about to be built.