Product Backlog Management
An emergent, ordered list
The Product Backlog is the single, emergent source of what is needed to improve the product: features, fixes, non-functional work, experiments. It is never complete. The Product Owner is accountable for it, including its content, availability and ordering, while the Developers contribute detail. Each item carries a description, an order and a size.
Refinement is continuous
Refinement is the ongoing act of breaking items down and adding detail; it is not an event and not a ceremony. The top of the backlog is small and well understood, while the bottom is coarse, because detail there would be wasted. Relative sizing is common, but Scrum mandates no technique and no unit.
Traps
- Expecting a fully detailed backlog up front; that contradicts emergence.
- Treating refinement as a formal meeting that must be scheduled, or as work only the PO does.
- Insisting that user stories or story points are required by Scrum; they are optional practices.
- Thinking the Product Backlog holds only user-facing features, or that the Developers own it. They own the Sprint Backlog.
- Inventing a Definition of Ready as a Scrum artifact; it is not in the Scrum Guide.
- Ordering purely by ROI or by the loudest stakeholder rather than by value, risk and learning.
Worked example
A backlog holds 400 items. Only the top 20 or so, roughly the next two Sprints, are refined into small, clear items. The rest wait. When a new idea arrives, the PO places it by value and risk rather than dropping it at the bottom by default.
Rule of thumb: refine just enough, just in time; enough detail for the next decision, no more.