The Product Backlog is an emergent, ordered list of what is needed to improve the
product, and the single source of work the Scrum Team undertakes. Its commitment
is the Product Goal.
Emergent
The backlog is never finished. It changes as the product, the market and the
understanding of both change. Items near the top carry enough detail to be
selected into a Sprint; items further down may be a single line. That gradient is
deliberate, because detail added early to items that are later reordered or
dropped is detail wasted.
Ready for selection
Items that can be Done by the Scrum Team within one Sprint are deemed ready for
selection in Sprint Planning. Product Backlog items usually acquire this degree
of transparency through refinement activities.
Attributes
Product Backlog items have the attributes of a description, order, size and
value. Sizing is the responsibility of the Developers. The Product Owner may
influence them by helping them understand and select trade-offs, but the people
who will do the work make the final estimate.
One product, one backlog
Where several Scrum Teams work on the same product, they share one Product
Backlog, one Product Goal and one Product Owner. Each team draws from the same
list rather than maintaining its own.
Common misconceptions
“A product can have several Product Backlogs, one per team.”
One product has one Product Backlog. Where multiple Scrum Teams work on it, they share that backlog along with one Product Goal and one Product Owner.
“The Product Backlog must be fully specified before a Sprint begins.”
It is emergent. Only the items near the top need enough detail to be selected; items further down remain coarse until refinement brings them into focus.
“Only the Product Owner may add items to the Product Backlog.”
Anyone may propose items. The Product Owner decides what is included and how it is ordered.
1 question test this concept
A stakeholder complains that the Product Backlog is unusable because items near the bottom are single lines with no acceptance criteria while items near the top are fully detailed. How should this be explained?
AThe stakeholder is right, and the team should detail every item to the same standard before the next Sprint.
BAcceptance criteria are not part of Scrum, so no item should have them.
CThe Product Owner should hide the lower part of the backlog from stakeholders.
DThe Product Backlog is emergent, and the gradient of detail is deliberate, since items near the top need enough detail to be selected while detail added early to items that are later reordered or dropped is wasted.
User Story Mapping, On giving a flat backlog a structure people can reason about.
Book
Essential Scrum, Chapters 5 to 6, on backlog content and grooming.
Template
Backlog refinement agenda, A ninety-minute structure covering the current Product Goal, what changed since the last session, and the items nearest the top that are not yet ready for selection.