DEEP Mnemonic

Basic

difficulty

Stage 2

Agile IQ® Level

Backlog

Practices

Agile

Framework

Introduction

The acronym DEEP helps to remember a widely accepted set of criteria, or checklist, to assess the quality of the Product Backlog.

An estimated Product Backlog is an essential part of an Agile Mindset

Estimation and slicing of items in the Product Backlog into smaller pieces is an important factor in getting work done in a short timeframe: "Deliver [work] frequently ... with a preference to the shorter timescale."

D.E.E.P.

Detailed Appropriately. Items on the Product Backlog that will be started in an upcoming Sprint need to be sufficiently well understood that they can go to a Sprint Planning session with confidence that they can be completed and achieve Done. Items that will not be developed for a while should be described with less detail.
Estimated. The Product Backlog is more than a list of all work for a product; 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, items on the product backlog will be added, removed, or reprioritized.
Prioritised. 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 Product Owner is able to maximise the value of the product or system being developed.

Actions to try

In backlog refinement:

Assess Product Backlog items against the DEEP criteria.
Assess how many items are likely to fit into the next 2-3 Sprints.
Assess whether those items help the Product Backlog meet the DEEP criteria.
If the Product Backlog doesn’t meet the DEEP criteria, start some research, high-level design, and discovery workshops with members of the team. Don’t spend more than 10% of the Sprint refining those items.
Apply what you’ve learned and document it against the Product Backlog items.
Stop when you have about 2-3 Sprints worth of well refined items.

Anti-patterns: Backlkog items aren't requirements

Backlog items should be written to a sufficient level of detail to enable the team to start work on them. They are not, in this way, similar to traditional requirements documentation. Requirements documentation is done to the level that (a) business stakeholders can agree (and sign-off) on what they will get, and (b) indicate a complete solution, prior to any work being done.

All fields are required.