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. The two words most often read past are "emergent" and "single", and both change what the artifact is for.
Emergent, ordered and never complete
The backlog is never finished. It changes as the product, the market and the understanding of both change, so a list that has not moved in two months has stopped being used. Items near the top carry enough detail to be selected into a Sprint, and items further down may be a single line. That gradient is deliberate, because detail added early to items later reordered or dropped is detail wasted.
Ordered is not the same as sorted into priority bands. A Product Backlog has one sequence, read top to bottom, and a set of items all labelled high tells the Developers nothing about what to take first. The order carries the Product Owner's judgement about value, risk and what the team needs to learn next, and it is how strategy reaches the work.
The single source of work
If the Scrum Team is doing it, it is in the Product Backlog. That covers fixes, technical work and investigation as much as new features, because a second queue arriving by other routes hides the real cost of the product from whoever is deciding what to build next.
One product has one Product Backlog. Where several Scrum Teams work on the same product they share that list, along with one Product Goal and one Product Owner, each team drawing from the same order rather than keeping its own.
What the Product Owner is accountable for
The Product Owner is accountable for effective Product Backlog management, which the Guide breaks into four activities.
- Developing and explicitly communicating the Product Goal.
- Creating and clearly communicating Product Backlog items.
- Ordering Product Backlog items.
- Ensuring that the Product Backlog is transparent, visible and understood.
Anyone may propose an item, and stakeholders, Developers and the Scrum Master usually do. What the Product Owner holds is the decision about whether a proposal is in and where it sits. The work may be delegated to others who write items or run refinement, and the accountability stays with one person, because a backlog two people can reorder has no order at all.
When the backlog may be updated
At any time. The Product Owner may change the Product Backlog whenever there is reason to, as may anybody acting on the Product Owner's behalf, and no event has to be waiting to make the change legitimate.
That is what emergent means in practice. The list is not a plan approved at a point in time and revisited on a schedule, it is the current best understanding of what would improve the product, and that understanding moves on the day a support ticket, a usage figure or a stakeholder conversation lands.
The alternatives all fail the same way, by inserting a delay between learning something and acting on it.
A change request process converts every piece of learning into administrative work, and the cost falls hardest on small corrections, which are the ones a backlog needs most often. What survives such a process is whatever somebody had the energy to argue for, which is not the same as whatever mattered most.
Waiting for the Sprint Review means the backlog is knowingly wrong for the rest of the Sprint. The Sprint Review is where the backlog is adapted with stakeholders in the room, and that makes it a scheduled opportunity rather than the only permitted one.
Requiring a refinement session with the Product Owner present confuses the accountability with the work. The accountability never moves, since the Product Owner decides what is in the backlog and where it sits. The work of writing and refining items may be delegated, and a change made by somebody acting on the Product Owner's behalf is still the Product Owner's change.
One boundary does hold. A Product Owner may reorder and rewrite the Product Backlog all Sprint long and may not reach into the Sprint Backlog, because that plan belongs to the Developers. Scope can be renegotiated with them as more is learned, which is a conversation rather than an instruction. Ordering the Product Backlog and changing the Developers' plan are different acts, and only the first is the Product Owner's to make alone.
Attributes and readiness
Refinement adds details such as a description, order and size. That list is worth holding precisely, because the 2017 Guide named description, order, estimate and value as item attributes and the 2020 Guide does not. Estimate became size, value dropped out of the list entirely, and a question offering the older four is offering the wrong edition.
Sizing is the responsibility of the Developers who will be doing the work. The Product Owner may influence them by helping them understand and select trade offs, and the number itself stays with the people who will do the work.
Items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in Sprint Planning, and they usually reach that degree of transparency through refinement. Notice what the Guide leaves out. There is no Definition of Ready, no required estimation scale and no rule that refinement is an event, so a team's readiness checklist is a local agreement rather than part of the framework.
The Product Goal is its commitment
Each artifact carries a commitment, and the Product Backlog's is the Product Goal. It describes a future state of the product and lives in the Product Backlog, with the rest of the backlog emerging to define what will fulfil it. A Scrum Team must fulfil or abandon one Product Goal before taking on the next.
That is what keeps the list from being a wish register. With a Product Goal in place, an item can be argued about in terms of whether it moves the product closer, which is a question that can be settled. Without one, the only argument available is about who asked and how loudly.
A backlog nobody can read
Transparency is not a pleasant property of a well kept backlog. It is the condition that makes ordering mean anything, because a list held in one person's head, or split across a spreadsheet, a tracker and a set of slides, cannot be inspected, and what cannot be inspected cannot be adapted.
The failure is rarely a missing backlog. It is a backlog that exists and that nobody except its author can read, where an item's title says nothing about what it means or why it sits where it does. Five hundred items in that state provide no transparency, and the honest repair is usually deletion, because a list too long to read is a list nobody orders.