| name | backlog-health |
| description | Review a delivery backlog for clear outcomes, ordering, dependencies, readiness, stale work, oversized items, and decision ownership without turning refinement into mandatory ceremony. |
Backlog Health
Use when an iterative team needs to know whether upcoming work is understandable and selectable without excessive rediscovery.
Procedure
- Identify the planning horizon and the subset of backlog likely to matter soon; do not refine the entire universe equally.
- Check that near-term items state a meaningful outcome or problem, relevant context, owner/decision authority, and acceptance evidence appropriate to the work.
- Separate product decisions still unresolved from implementation work that is genuinely ready for engineering/design execution.
- Surface hard dependencies, external approvals, missing research, and ambiguous scope that would block progress.
- Split items only when doing so creates independently useful or testable outcomes; avoid arbitrary size rules.
- Remove, archive, or revalidate stale work whose assumptions, priority, owner, or product context have changed.
- Keep defects, technical work, discovery, and delivery items distinguishable enough to apply the right readiness standard.
- Confirm ordering reflects current priorities and capacity rather than historical ticket position.
Decision rules
- A large backlog is not an accomplishment.
- Only near-term work needs high refinement fidelity.
- Story-point or item-size conventions are team tools, not universal laws.
- Product Manager owns product intent; Scrum Master protects flow/readiness rather than rewriting scope.
Quality gate
The backlog is healthy when near-term work is understandable and ordered, unresolved decisions and dependencies are visible, stale work is not masquerading as commitment, and specialists can select work without reconstructing basic intent from old conversations.
