The Product Backlog: one ordered list, never finished

Every team has a list somewhere. In many it is a spreadsheet of requests that only grows, with some items two years old and nobody quite sure who asked for them. The Product Backlog is that list with rules, and the rules are what make it useful.

What the Guide says

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Each of those words does something.

• Emergent. It is never complete or fixed. New items arrive as the product, the market and the team's understanding change, and old ones leave.
• Ordered. Position carries information. The item at the top is next, and an item's place says how much it matters relative to the rest. A list sorted only by date or by who asked is not ordered in this sense.
• Single source. The team's work comes from this list. Work that arrives by another route, such as a request made directly to a Developer, is work the Product Owner cannot see or order.

The Product Owner is accountable for it, which the Guide breaks down into developing and communicating the Product Goal, creating and communicating items, ordering them, and making sure the whole thing is transparent, visible and understood. The Product Owner may delegate the work and remains accountable. Anyone who wants to change the Product Backlog can do so by trying to convince the Product Owner.

The Product Goal

The Guide attaches a commitment to the Product Backlog: the Product Goal. It describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog, and the rest of the backlog emerges to define "what" will fulfil it.

A Product Goal is the long-term objective of the team. The Guide says the team must fulfil or abandon one objective before taking on the next. That rule is more demanding than it looks. It stops a team from pursuing three directions at once and calling it a roadmap.

Without a goal, a backlog is a pile. With one, every item can be asked a question: does this help reach it?

What a backlog item is

The Guide does not prescribe a format. An item might be a user story, a bug, a technical improvement, an experiment or a piece of research. What matters is that it improves the product and that the team can understand it. Our post on user story anatomy covers the most common form.

Attributes often vary with the domain of work, and the Guide mentions a description, an order and a size as typical. These are added through refinement.

Refinement keeps the top clear

Product Backlog refinement is, in the Guide's words, the act of breaking down and further defining Product Backlog items into smaller, more precise items. It is an ongoing activity to add details such as a description, order and size.

The result is a backlog shaped like a pyramid on its side: precise and small at the top, vague and large at the bottom. The Guide says items that can be Done within one Sprint are deemed ready for selection at Sprint Planning, and that they usually acquire that degree of transparency after refining activities.

There is no required meeting for it, and the Guide leaves the timing to the team. One pattern teams use is a short regular session each Sprint to look at the next few items, in addition to the conversations that happen as the Product Owner and Developers work. The Developers who will be doing the work are responsible for sizing, and the Product Owner may influence them by helping them understand and select trade-offs.

As a rule of thumb that is ours, not the Guide's, keep refined only what the team is likely to need over the next couple of Sprints. Items further down are better left as one-line placeholders, because detail added too early goes stale.

How the SBOK names it

In the SBOK® Guide, the same list is called the Prioritized Product Backlog, and its description is more prescriptive. The Product Owner develops it, containing a prioritised list of business and project requirements written as epics, which are high-level user stories, based primarily on value, risk or uncertainty, and dependencies. It may also be called the Risk Adjusted Product Backlog, because it includes assessed risks. Items are refined through a dedicated process called Refine Prioritized Product Backlog, in which a review meeting discusses and incorporates changes, and the backlog is continuously updated and maintained.

The two descriptions agree on the essentials: one ordered list, owned by the Product Owner, kept current. The SBOK adds explicit treatment of risk in the ordering, which the next post, on ordering the Product Backlog, takes up.

Signs of a healthy backlog

• The top ten items can all be explained in a sentence, and everyone on the team can say why they are there.
• The Product Goal is written down and visible.
• Old items are removed or marked as out of scope, not left to accumulate.
• The Developers can pick up the top item tomorrow without a meeting.
• Stakeholders can see the backlog and find their request on it, or find out why it is not.

Common mistakes

• A graveyard. Hundreds of items that will never be done make the real ones hard to see. If an item has been at the bottom for a year and nobody has asked about it, consider deleting it. It can always be re-added.
• A backlog the Product Owner alone can read. If the items are codes or jargon, the "transparent, visible and understood" test fails.
• Detail everywhere. Writing full descriptions for items months away spends effort on things that will change.
• Multiple backlogs for one product. The Guide says several Scrum Teams on one product share one Product Backlog.
• The Product Owner as a secretary. Collecting requests is not ordering them. The accountability is to make choices.
• Using it as a commitment. The backlog is a forecast of what may be built, not a promise to build all of it. The Agile Manifesto principle that simplicity, the art of maximising the amount of work not done, is essential applies directly here.

How to practise it

A backlog looks fine until you have to rank it under pressure. In the simulator, the team ranks a candidate backlog by value and risk at step 1.5, and the backlog is reordered again at refinement when a change request arrives mid-Sprint.