Learning Objectives
By the end of this lesson you will be able to:
- Explain each of the four DEEP criteria with a concrete example
- Apply the DEEP model as a pre-sprint health check
- Identify which DEEP criterion a given backlog problem violates
- Distinguish between "refinement" and "grooming" and explain why the distinction matters
What is DEEP?
DEEP is a backlog quality model proposed by Roman Pichler and Mike Cohn. A healthy Product Backlog should be:
- Detailed appropriately
- Estimated
- Emergent
- Prioritized
These aren't aspirational goals — they're practical checkpoints. When a sprint starts poorly, one of the DEEP criteria is usually the culprit.
D — Detailed Appropriately
Not all backlog items need the same level of detail. Items near the top (about to be worked on) need well-defined acceptance criteria. Items farther down can be rough — just enough to understand what they're about.
The common failure: Either everything is vague (the backlog is a pile of ideas, not a plan), or everything is over-specified (teams write novels for stories that won't be worked on for six months, then find the requirements have changed).
The right model:
- Sprint Ready: Complete acceptance criteria, clear DoD, estimated, no known blockers
- Next 2-3 sprints: Rough acceptance criteria, high-level estimate, dependencies identified
- Beyond that: Title + one-paragraph intent. Nothing more.
Pro Tip: A story shouldn't have detailed AC written until it's within 1-2 sprints of being worked on. Writing detailed requirements too early is waste — they'll likely change before the story reaches the sprint.
E — Estimated
Every item near the top of the backlog should have an estimate. Not necessarily in Story Points — even T-shirt sizes work. The purpose of the estimate is to enable planning and forecasting.
The common failure: The PO adds new stories to the top of the backlog without estimates. Sprint Planning becomes a surprise session where the team has to estimate on the spot, under time pressure, for items they're expected to commit to immediately.
The fix: Estimates are the team's responsibility and should happen in Refinement, not in Sprint Planning. Sprint Planning should be selecting from a pre-estimated, pre-refined backlog, not estimating from scratch.
E — Emergent
The backlog should change over time. Requirements evolve, priorities shift, new information arrives. A good backlog reflects this: items are added, removed, split, and re-estimated as understanding improves.
The common failure: The backlog is treated as a contract. Items locked in from a discovery phase months ago are still at the top in the same form, even though the business has changed around them. Teams are implementing requirements that no longer reflect reality.
The fix: Treat the backlog as a living document with a regular (weekly or bi-weekly) review cadence. Items that haven't been touched in 3+ sprints should be re-evaluated — do they still belong in the product?
P — Prioritized
Items are ordered by value, not by technical preference or who asked loudest. The most important item is always at the top. The team should always be able to answer: "If we could only finish one more thing this sprint, what would it be?"
The common failure: Multiple items are all Priority 1. "Everything is urgent" means nothing is prioritized. The real priorities hide behind the stated ones.
The fix: True prioritization means choosing. Items cannot all be equal. The PO's job is to make the hard call about what comes first. If everything is Priority 1, the PO hasn't done the job.
Pro Tip: Use "ordered" instead of "prioritized" — it forces the conversation. You can have two Priority 1 items. You cannot have two items both in position #1.
Refinement vs Grooming
These terms are often used interchangeably, but they represent different activities:
- Refinement (the Scrum term): The ongoing process of adding detail, estimates, and order to backlog items. A continuous activity happening throughout the sprint.
- Grooming (older term, now discouraged): A formal meeting to review and clean up the backlog. The term implies a single event rather than a continuous practice.
The Scrum Guide refers only to "Product Backlog refinement" — an ongoing activity, not a meeting. Teams that treat it as a meeting (one 1-hour session per sprint) typically have backlogs that don't meet the DEEP criteria.
Summary
DEEP is a diagnostic tool, not just an acronym. When sprint planning gets chaotic, find which criterion is failing: is the top backlog too vague? Missing estimates? Stale? Unprioritized? Each failure has a different fix. Teams that run a 5-minute DEEP check before every sprint planning session prevent most planning problems before they start.