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. Two words in that definition carry most of the weight, "emergent" and "single", and each of them changes what the artifact is for.
The Product Backlog is emergent, ordered and never complete
The backlog is never finished, because 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, while items further down may be a single line. That gradient is deliberate. If an item is reordered to the bottom or dropped, every hour spent writing detail for it was spent for nothing. An item forty places down that reads "rate limit the public API" may be unnecessary by the time it reaches the top, because a managed gateway may already be doing the job, so one line is all it needs today.
Ordering is the other half of that gradient. Priority bands do not produce an order, because a Product Backlog has one sequence, read top to bottom, so 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, so a security patch somebody slipped in on a Friday and an afternoon spent reproducing a bug both belong on the list. 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. If several Scrum Teams work on the same product, they share that list along with one Product Goal and one Product Owner, and each team draws its next work from the same single order.
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. The Product Owner holds the decision about whether a proposal goes in and where it sits. The work may be delegated, so other people may write items or run refinement, but 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 come round first for the change to be legitimate.
That is what emergent means in practice. A plan is approved at a point in time and revisited on a schedule, while the Product Backlog is the current best understanding of what would improve the product. That understanding moves on the day a support ticket, a usage figure or a stakeholder conversation lands, and the list moves with it.
Every process that delays a change fails in the same way, by inserting a gap 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. Such a process passes whatever somebody had the energy to argue for, which is a different thing from 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, so it is one scheduled opportunity to change the list, and every other day of the Sprint stays open too.
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, so 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, but may not reach into the Sprint Backlog, because that plan belongs to the Developers. Scope can be renegotiated with the Developers as more is learned, and the word renegotiated describes a conversation, so neither side settles it alone. Ordering the Product Backlog and changing the Developers' plan are therefore different acts, and only the ordering is the Product Owner's to settle alone.
Product Backlog item 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 Developers.
Enough detail is also what readiness amounts to. 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. The Guide stops there. It names 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 and never a requirement of the framework.
The Product Goal is the Product Backlog's commitment
The framework is firmer about commitments than about readiness. Every artifact carries one, and the Product Backlog's commitment is the Product Goal. The Product Goal describes a future state of the product and lives in the Product Backlog, while the rest of the backlog emerges 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. If the Product Goal is to bring checkout failures below one in a thousand, an argument about adding a new payment method has something to settle it, because the question becomes whether the method moves that number. Without a Product Goal the only argument available is about who asked and how loudly.
A backlog nobody can read
An argument about the order needs a list everybody can read. Transparency is the condition that makes ordering mean anything. A list held in one person's head, or split across a spreadsheet, a tracker and a set of slides, cannot be inspected, and a list nobody can inspect is a list nobody can adapt.
A missing backlog is rarely the problem. The usual problem is a backlog that exists and that nobody except its author can read, in which an item's title says nothing about what it means or why it sits where it does. A ticket called "fix the import" tells the Developers nothing about which import or what fixed would look like, and five hundred lines in that state provide no transparency at all. The honest repair is usually deletion, because a list too long to read is a list nobody orders.
Transparency is also where the Scrum Master's part in this artifact sits. The Guide gives the Scrum Master no say over what the backlog contains, but it does ask for help in making the Scrum Team understand the need for clear and concise Product Backlog items. That service lands at the moment an item is written. By the time the list has reached five hundred unreadable lines the same fault has turned into an impediment, and causing its removal is the Scrum Master's work.