One Product, Many Product Backlogs

Ever seen a bug backlog? Yep, some Scrum teams create a separate backlog just for bugs. How about a technical-debt backlog? This one is a favorite of Ryan’s from past coaching experiences: The Backlog of Broken Promises and Crushed Dreams, where every story we promised to deliver—but didn’t—went to die. Crazy right? Unfortunately, it’s not uncommon for Scrum teams to have multiple backlogs, especially on products that involve multiple Scrum teams.

When a product-development effort requires many development teams, the product owner often needs to delegate the task of refining the product backlog. In that situation, allocating each team their own separate product backlog might seem like the right thing to do. But in our experience, going down that path only leads to tears. When teams working on a single product have separate product backlogs:

• There’s no holistic view of what needs to be accomplished, so the teams will start to diverge, leading to a product that’s no longer cohesive–and possibly not even functional.

• Each team will construct their product backlog in their own way, rendering the overall product vision and goals useless.

• The underpinning architecture won’t be consistent across teams, leading to technical debt and the need to rework features that aren’t coherent.

• Dependencies between teams won’t be considered, resulting in blame and conflict.

• Trying to integrate all of the different teams’ work will add unnecessary complexity and time to sprints.

• No single team is accountable to stakeholders for the quality and value of the product.

Bottom line: The product backlog is the single source of truth for every kind of work in Scrum. There should only be one product owner and one product backlog on a product-development effort, regardless of the type of work or number of teams. Having one product backlog provides a holistic view of the future of the product. It creates cohesion regardless of the number of development teams that are working on the project. A single product backlog results in better conversations with stakeholders and clearer increment inspections during sprint reviews.

What do you do if you have multiple product backlogs? Your top priority should be to work with the product owner to help them create a single clear, well-understood vision of the product. Here are some techniques we recommend for starting the consolidation process:

1. Work with your product owner to gather every product backlog. This sounds a little silly, but there are likely many spreadsheets, notebooks, and napkins in your organization with important product information and backlog items. Check with the development team(s). They probably have lists of technical debt and “things we intend to do later,” captured somewhere, that should also be included in the product backlog.

2. Ask the product owner to merge all of these lists into a single product backlog. The new backlog will be sprawling and seem overwhelming at first, but that’s okay. You’re about to prune it into something more manageable.

3. Delete anything that’s older than six months, as you likely won’t ever do the work for those features. And if that work is important, it will reappear via feedback from customers and stakeholders. Understandably, your PO may be really nervous about truly deleting any PBIs. But trust us, it’s better for everyone in the organization to axe PBIs that are old and stale. The PO may be tempted to create a separate list of “deleted” PBIs “just in case,” but as we discuss in the next section, that’s a bad idea. The product backlog (singular!) should be the one and only source of truth for the project.

4. Group similar items together and help your product owner create new product backlog items, if needed. Refine and rework these items as you merge them together to create a unified product backlog.

5. Help the product owner order the newly built product backlog. Discuss what needs to be worked on next in order to deliver the most value in the next sprint.

6. Facilitate a product backlog refinement session with the Scrum team(s). Helping the team(s) re-establish a holistic vision of the product is important. A refinement session or two can help get everyone back on the same page and allow them to see what has changed now that all of the work is visible.

7. Have your product owner share the updated product backlog during the next sprint review.

Joe asks:

Who can update the product backlog?

The product owner is solely accountable for the state of the product backlog. However, other people may update it at the product owner’s discretion. But make sure the PO is cautious about sharing this power: If several people can edit the product backlog, the result can end up being a jumbled mess. Work with the product owner to find the appropriate dynamic for your situation.