Managing the Product Backlog
Domain 3, Managing the Product Backlog, tests practical backlog ownership: structure, refinement, ordering, user stories, acceptance criteria, estimation, and forecasting. The exam favors answers that keep the backlog alive and appropriately detailed rather than fully specified upfront.
Core rules
- The Product Backlog is the single ordered list of what might be needed to improve the product. It is emergent; the Product Owner orders it, and the team helps refine it.
- DEEP summarizes good backlog quality: Detailed appropriately, Emergent, Estimated, Prioritized. Items near the top are small, clear, and ready for Sprint Planning; distant items stay coarse.
- Refinement is ongoing collaboration to clarify, split, and estimate items. It is not a formal Scrum event and should not become a gate that blocks Sprint Planning.
- User stories often use As a role, I want goal, so that benefit. INVEST helps assess quality; the 3Cs are Card, Conversation, Confirmation.
- Acceptance criteria are testable conditions for a backlog item. They differ from the Definition of Done, which applies to every Increment.
- Ordering considers value, risk, cost, dependencies, and learning. Techniques include MoSCoW, Kano, weighted shortest job first, and cost of delay. Story points are relative estimates; velocity supports forecasting, not cross-team comparison.
- A roadmap is a communication and forecasting aid, not a fixed contract.
Worked example
A backlog has 150 items; the top story is a vague improve reporting item. A weak answer details and estimates all 150 items. A better answer refines only the near-term items: split improve reporting into thin slices, add acceptance criteria, estimate the top slices with the team, and leave later items coarse. Reasoning: DEEP directs investment where uncertainty is highest; detailing everything creates waste and false precision.
Traps
Do not treat the backlog as a fixed requirements document. Do not make every item equally detailed. Do not let the team reorder the backlog or let the loudest stakeholder set priority. Do not equate acceptance criteria with the Definition of Done. Do not use velocity to rank teams. Do not treat refinement as a mandatory ceremony or Definition of Ready as a Scrum rule.