One Product Backlog for several teams

The idea is simple and the practice is hard. Several teams, one product, one list of what is wanted. When the list is shared, priorities are honest: every team sees the same order, and no team builds what the others do not need. When it is not shared, each team grows its own list, priorities diverge and the product comes out in pieces that do not fit. The Guide chooses the shared list and leaves the details to those who must make it work.

What the sources say

The Scrum Guide states the rule in its description of the Scrum Team. If Scrum Teams become too large, they should consider reorganising into multiple cohesive Scrum Teams, each focused on the same product, and therefore they should share the same Product Goal, Product Backlog and Product Owner. It also says that if there are multiple teams working together on a product, they must mutually define and comply with the same Definition of Done. The Product Owner is one person, not a committee, and may delegate work while remaining accountable.

The SBOK® Guide agrees on the principle and adds roles for large projects. It describes a Chief Product Owner who coordinates the work of several Product Owners and maintains the overall Prioritized Product Backlog, using it to coordinate work top-down through the Product Owners of each team. The Chief Product Owner is responsible for the final deliverables, whereas each team's Product Owner is responsible for the deliverables of their own team. The SBOK also requires a Product Owners Collaboration Plan that defines how many teams a Product Owner can serve, how the work of gathering requirements from stakeholders is divided, how the backlog is updated and how Product Owners collaborate with multiple teams. It notes that each team still collaborates with only one Product Owner, while one Product Owner can serve more than one team.

LeSS, a scaling approach that stays close to the one-team rules, describes a single Product Backlog because it is for a product and not a team, with an optional overall refinement meeting that includes the one Product Owner and people from all teams to decide which teams are likely to implement which items.

The tension

A single list is a single point of decision. One Product Owner must order items that affect eight teams and serve stakeholders across the organisation. The load can be unmanageable. The alternatives are worse: separate lists per team recreate the fragmentation the rule is meant to prevent.

The resolution in most approaches is to keep one list, and to distribute the Product Owner's work without distributing the accountability. The Guide allows this: the Product Owner may do the work or delegate it, and remains accountable.

Workable arrangements

One Product Owner and one backlog, with area experts. The Product Owner is accountable for the order. Helpers, often called area product owners, take responsibility for the detail in parts of the product, refining items and representing the stakeholders. The Product Owner decides across areas. This is the closest to the Guide and to LeSS.

A Chief Product Owner with team-level Product Owners. The SBOK model. The Chief Product Owner keeps the overall backlog and decides cross-team priorities, with each team's Product Owner managing the detail for their team. The key requirement is that the Chief Product Owner can truly decide, and does not become a committee chair.

One backlog, team views. The tool shows one ordered list, with filters or tags so that each team sees the items it is likely to take. A team's "backlog" is a view of the shared one, not a separate list.

Shared ordering at the top, local detail below. The first few Sprints' worth of items are ordered by the Product Owner for the whole product. Further down, items are grouped by area and refined by the area's team.

Whatever the structure, certain things are constant: a single place where the order is decided, an open record of that order, and a rule for how items move to a team.

How teams choose items

There are two common ways.

The Product Owner assigns. The order and the assignment come together: top items go to the teams that can do them. Simple, but it can reduce team ownership.

Teams select. In a joint planning session, representatives from all teams look at the top of the list and agree among themselves who takes what, taking account of skills, dependencies and capacity. LeSS describes this: team members decide among themselves how to divide the items and discuss opportunities for shared work. The Product Owner is present to answer questions and resolve conflicts. This fits the Guide's idea of self-managing teams.

The second tends to produce better results when the teams are cross-functional and feature-oriented. Component teams force the first, because items must go to the team that owns the code.

A worked example

This is an illustrative product built by four teams: search, booking, payments and tutor tools. A single Product Owner orders one backlog of 120 items. Four area helpers, one from each team, refine items in their area.

Every second Tuesday, before Sprint Planning, the Product Owner and the four helpers hold a refinement session on the top 25 items. They mark each with a likely team and its dependencies. At joint planning, the teams meet and review the top 25. Booking and payments agree that "pay with saved card" involves both and will be done by payments with a booking Developer joining for the first three days. Search takes three items, tutor tools four.

During the Sprint, the helpers refine the next batch. A new request arrives from the sponsor to add group bookings. The Product Owner asks the helpers what it would take, orders it against the top items and decides that it goes after the current goal. Everyone sees where it sits, because there is one list.

At the Review, stakeholders see one integrated Increment and one backlog. When the sponsor asks "what is next?" there is one answer.

Failures

• Separate backlogs that drift. Each team plans its own work and the product incoherently ships.
• A Product Owner with no decision rights. The role becomes a relay. See the proxy Product Owner problem.
• A Chief Product Owner who is a bottleneck. If every decision goes through one person, teams wait.
• Component teams. Each item needs several, so the backlog is full of dependencies. Re-form around features where possible.
• No shared Definition of Done. Items "done" in one team are not usable in another. See one Definition of Done across teams.
• A giant list. Prune. See backlog size and the long tail.

How to practise it

If you have several teams, ask who decides what is next across all of them and how a team learns it. Draw the answer. In the simulator the Product Owner role orders a single backlog for a team, which is the unit that a multi-team backlog repeats.