PSM I Product Backlog Management: Ordering, Refinement and Sizing

Product Backlog management is the ongoing work of keeping the Product Backlog useful: deciding what is in it, ordering it, adding detail to items as they approach selection, and keeping it transparent to everyone who relies on it. The Scrum Guide makes the Product Owner accountable for effective Product Backlog management, while the whole Scrum Team takes part in the refining work.

The Guide lists four things that accountability covers:

• 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.

The Product Owner may do this work personally or delegate parts of it to others, but remains accountable either way. This lesson covers how the Product Backlog behaves, who does what with it, ordering, refinement, sizing, splitting, what belongs in it, how it changes during a Sprint and how several teams share one. Deciding what "value" means and working with stakeholders and customers is covered in the lesson on product value; forecasting and release planning from the Product Backlog has its own lesson.

The Scrum Guide defines the Product Backlog as an emergent, ordered list of what is needed to improve the product, and says it is the single source of work undertaken by the Scrum Team. Each part of that sentence has consequences.

• Emergent means the list is never finished. Items appear, change, split and disappear as the team and stakeholders learn from each Increment and as market and business conditions shift. A Product Backlog that never changes is a sign that nobody is inspecting and adapting.
• Ordered means every item has its own position. The order tells the Scrum Team which items the Product Owner wants considered first; it does not assign items to people or show the current Sprint's plan.
• Single source of work means anything that takes the Scrum Team's capacity goes through the Product Backlog rather than around it.

The Product Goal lives in the Product Backlog

In the 2020 Guide every artifact has a commitment, and the Product Backlog's commitment is the Product Goal. The Guide says the Product Goal is in the Product Backlog and that the rest of the Product Backlog emerges to define what will fulfil it. Two practical consequences follow:

• Items that no longer serve the Product Goal are clutter. The Product Owner can remove them. A long tail of outdated requests drags refinement into work nobody will build and makes the real order harder to read; the test for keeping an item is whether it still helps towards the goal, not how it got there or how old it is.
• The Scrum Team pursues one Product Goal at a time: it fulfils (or abandons) one objective before taking on the next. Ideas likely to serve a later goal can stay in the same Product Backlog, ordered below the current work, and be refined when they become relevant. They do not need a second backlog, and they do not need to be deleted.

What a transparent Product Backlog looks like

The Product Owner is accountable for the Product Backlog being transparent, visible and understood. Scrum's inspections are only as good as the artifacts they look at, so in practice that means:

• One shared backlog that is the real one. The order everyone can see is the order the Product Owner is actually working to, kept current as decisions change. If the "true" order lives in a private file or someone's head, the shared list is misleading and every forecast built on it is wrong.
• Visible to everyone who relies on it, stakeholders as well as the Scrum Team, so they can see where their needs stand and raise concerns with the Product Owner.
• Understood by its readers. Items are written in language the people reading them understand, saying what each item is for. Internal shorthand that only the Developers can decode makes the backlog visible but not understood.
• Clearly ordered, so anyone can tell what comes next.

The Product Owner owns the content and order of the Product Backlog; the Developers size items and share the refining work; the Scrum Master helps with technique; stakeholders influence it by convincing the Product Owner. Nobody else holds a veto or an approval step.

Changing the Product Backlog means convincing the Product Owner

The Guide says that for Product Owners to succeed, the entire organization must respect their decisions, and that those wanting to change the Product Backlog can do so by trying to convince the Product Owner. So a request that arrives anywhere else, such as an email to a Developer or a word with the Scrum Master, is passed to the Product Owner, who decides whether and where it goes. Wherever the request lands, the decision about whether it enters the backlog and where stays with the person accountable for it.

The Guide also says where the Product Owner's decisions become visible: in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

When refinement is not working

If refinement wanders or keeps producing vague items, the Scrum Master's contribution is to coach and teach: techniques for writing clear, concise items, ways to structure the session, how to involve the Developers. The Scrum Master serves the Product Owner and the team by building their capability; the decisions about the items, and how the team organizes its refining work, stay with them.

Ordering the Product Backlog is the Product Owner's accountability, and the Scrum Guide prescribes no ordering technique. The aim is to maximize the value of the product over time, not the value of each item on its own, so the Product Owner can weigh several factors together:

• Value: what the item is worth to users, customers and the organization.
• Risk: an item that tests an uncertain integration or technology can belong near the top even if users gain little from it directly, because it reduces the risk to everything that depends on it.
• Dependencies: an item that unblocks several high-value items may move up for that reason alone.
• Learning: Scrum is founded on empiricism. When the value of a large item is uncertain, a small experiment ordered ahead of it turns a guess into evidence and limits the cost of being wrong.

None of these needs approval from the Developers, the Scrum Master or a stakeholder vote. The Developers explain technical risk and cost; the Product Owner decides the order. An item being "technical" does not move its ordering to the Developers.

Ordered, not merely prioritized

An order gives every item its own place. Priority labels shared by many items create ties and leave the Developers guessing at Sprint Planning; any scheme that puts many items in one bucket has the same problem, however many buckets there are. Grouping or categorization can still help stakeholders as a complementary practice, provided it sits on top of a single clear order rather than replacing it.

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise items. The Scrum Guide calls it an ongoing activity that adds details such as a description, order and size, with attributes that often vary with the domain of work.

An activity, not an event

Refinement is not one of the five Scrum events (the Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective). So the Guide gives it no timebox, no fixed frequency and no designated facilitator, and it is not a phase completed before the first Sprint. Earlier editions said refinement usually consumes no more than 10% of the Development Team's capacity; the 2020 Guide removed that figure. How much time refinement takes is a self-management decision for the Scrum Team.

It happens inside the Sprint

A new Sprint starts immediately after the previous one ends, so there is no "gap between Sprints" in which to prepare items. Refinement therefore happens during each Sprint, as part of the team's ongoing work; the Guide's description of the Sprint says the Product Backlog is refined as needed. When refinement keeps being squeezed out, the Scrum Team makes room for it as part of its Sprint work; Sprint Planning keeps its own purpose and timebox.

Who takes part

• The Product Owner clarifies needs and orders the items.
• The Developers clarify, split and size the work they will do. A Product Owner who refines alone and presents finished items at Sprint Planning keeps that understanding out of the Developers' hands until it is too late, and Planning fills with items that are too large or unclear.
• Experts and stakeholders can be invited to explain a need nobody on the team fully understands, such as a specialist legal or domain constraint. The Guide does not limit who helps with refinement, and it explicitly allows the Scrum Team to invite others to Sprint Planning for advice. They contribute knowledge; the accountabilities for ordering and sizing stay where the Guide puts them.

Items gain detail as they rise towards selection: items near the top of the Product Backlog are the most refined, and items further down stay broad. This follows directly from the backlog being emergent. Detail written long before an item is selected goes out of date as the team and stakeholders learn, and effort spent on items that may never be built is waste.

• A new idea can enter the Product Backlog as a one-line item with no size. Description, acceptance criteria and size are added if and when it rises.
• Refinement effort should be concentrated on items likely to be selected soon. Writing full acceptance criteria for hundreds of items, or freezing their details, keeps the waste.
• Sizing precision can match proximity: rough sizes far down the order are fine; precision matters for items that are about to be taken into a Sprint.

Who sizes, and how

The Guide states that the Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs, but does not size items, and neither does a business analyst or manager outside the team. Size is still one of the details refinement adds, so dropping it altogether is not the answer either.

The sizing technique is left to the team. Story points, T-shirt sizes, ideal days or counting items are all complementary practices; the Guide prescribes none of them. Ordering does not depend on every item having a precise size first: sizing effort follows the order, concentrated near the top, and every Sprint still aims to produce a valuable, usable Increment.

An item is ready for selection when the Scrum Team can get it Done within one Sprint. The Guide says that Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in Sprint Planning, and that they usually acquire this degree of transparency after refining activities. An item too large for one Sprint is therefore split during refinement into smaller items that each fit; the Sprint length is fixed and the Increment must be Done within it.

Good reasons to split

• The item is too large to get Done within one Sprint.
• Splitting lets the most valuable part be ordered ahead and delivered sooner, which gives the Product Owner finer control over value.

Splits are driven by size and value. Scrum Teams are cross-functional and the Developers work on items together, so how skills or people are distributed is not a basis for splitting.

Thin slices, not layers or activities

Each Sprint should produce a usable Increment that meets the Definition of Done. A split that passes the "fits one Sprint" test can still fail the "usable" test.

Definition of Ready is optional

Many teams adopt a "Definition of Ready" checklist. The Scrum Guide does not define one: its three commitments are the Product Goal, the Sprint Goal and the Definition of Done. A Definition of Ready is a complementary practice the team owns and adapts. It does not replace refinement, it does not belong to the Scrum Master, and it should not become a rigid gate. The Guide's test is whether the item can be Done within one Sprint; a checklist is a means to that, so entries that do not apply to a particular item should not keep it out of Sprint Planning.

The same applies to item format: the Guide does not require user stories, use cases or any particular template. Teams may use them; Scrum leaves the format to the people using it.

Any work that takes the Scrum Team's capacity belongs in the Product Backlog, where the Product Owner can order it against everything else. Hidden work distorts forecasts, breaks transparency and undermines the Product Owner's accountability for value.

• Technical debt that slows the team down affects value, so it becomes visible items the Developers size and the Product Owner orders. The Developers explain the impact; how debt ranks against features is agreed with the Product Owner. Debt work that is not in the backlog is hidden from that decision, and making it visible only after it is done still leaves the plan opaque while it is being made.
• Technical improvements discovered during refinement, such as rebuilding a shared component that would make a feature cheaper, are raised so they become items with their own size.
• Experiments and spikes, such as testing whether a database can handle the expected load, are items too, so their cost and result are visible.
• Side requests and "favours" that managers ask of individual Developers are routed to the Product Owner. Any second channel for work, however informal, takes capacity the Product Owner cannot see or order.

Qualities: Definition of Done or Product Backlog?

Standing qualities belong in the Definition of Done because every Increment must meet them when it is created; quality deferred to later work means the earlier Increments were never really Done.

Because the Product Backlog is emergent and the Product Owner is accountable for its content and order, the Product Owner can update it whenever a change is useful: it is not frozen between events, and changes do not need the Developers' approval. The Sprint Review is a natural place for adjustments, because there the Scrum Team and stakeholders discuss what has changed in their environment and the Product Backlog may be adjusted to meet new opportunities, but nothing restricts changes to the Review.

The backlog changes because of what Scrum is built to notice: feedback on each Increment shows what users need next, and market and business conditions shift during development.

Product Backlog changes versus the current Sprint

Reordering the Product Backlog does not rewrite the current Sprint. The Sprint Backlog is a plan by and for the Developers, and during the Sprint no changes are made that would endanger the Sprint Goal. So when the Product Owner moves an item to the top mid-Sprint:

• it becomes next in line, which mainly shapes the next Sprint Planning;
• scope may be clarified and renegotiated with the Product Owner as more is learned, and the Developers decide whether taking the item on now still lets them meet the Sprint Goal;
• the Sprint Backlog stays the Developers' plan, and the Sprint continues; the Guide reserves cancellation, by the Product Owner, for a Sprint Goal that has become obsolete.

Stability without a freeze

Developers who find constant reordering unsettling get their stability from the Sprint Goal and their own Sprint Backlog, not from a frozen Product Backlog. Holding the Product Backlog still would slow the product's response to change, which is the reason the backlog is emergent in the first place.

When several Scrum Teams build the same product, the Scrum Guide says they should share the same Product Goal, Product Backlog and Product Owner. So the product keeps one backlog and one ordering accountability, however many teams draw from it.

Shared work brings dependencies between teams. Refinement is where items are prepared for selection, so it is the place to expose dependencies early, by refining upcoming items across the teams that will be involved rather than discovering them at each team's Sprint Planning or at the Sprint Review.

Ordering helps too. If one team's high-value item depends on work another team would do from an item far down the order, the Product Owner can order that enabling item ahead, because dependencies are a legitimate ordering factor, and both teams can refine the two items together. Each team's current Sprint is still its own Developers' plan, so the dependency is handled through the order and joint refinement for upcoming Sprints.