Why single backlog for cross-functional teams is important?

Question

I have 4 teams working on same product. Currently we use separate backlog for each one. When creating a story PO puts it into proper backlog in advance. His list of rough ideas (before they become stories in JIRA) and their priority is tracked in his separate system.

I'm regularly thinking about having a single backlog, as Scrum prescripts. But I see that in practice having single backlog can just create mess:

1. I like to have a rough stories allocated for 1-2 sprints ahead for each team. If we have single backlog it means that I will have 4 active sprints and 4-8 pending on a JIRA list view. Which is hard to manage
2. I will have all bugs for all the teams in a single place, and will have to additionally put special tags on them to understand which team is responsible.
3. Backlog will be huge!
4. Backlog grooming may get messy, since a lot of people will be bored while grooming other team's items.

What do you think? Am I missing something?

Answer 1

The biggest advantage of having a single backlog is that it makes priorities clear.

If there are multiple backlogs then priority can be obscured. For example, is the second item on the Team X backlog more or less important than the second item on the Team Y backlog?

This is important when:

• There are shared resources between the teams - such as a shared database administrator or just one performance test environment. When contention for the shared resource happens then a priority call needs to be made.
• There are dependencies between the teams - if story A needs to be done by Team X to unblock Team Y, does it have priority over other stories in the Team X backlog?

If you have none of these issues and multiple backlogs work for you then that is fine.

I will have all bugs for all the teams in a single place, and will have to additionally put special tags on them to understand which team is responsible.

Why must one team be responsible for a bug? All teams should be able to work on any backlog item.

Answer 2

At scale, you might want to look at a Hierarchical Backlogs. This way each team can have their own manageable backlog to groom/plan but there's an overall backlog that can be utilized for things like increment planning.

Kenneth S. Rubin (author of Essential Scrum: A Practical Guide to the Most Popular Agile Process) has a good chapter about Which and How Many Backlogs. In particular, check out the section called Large Products—Hierarchical Backlogs.

Whenever possible, I prefer one product backlog even for a large product like Microsoft Office. However, we need to be practical when applying this rule. On a large product development effort to create something like a cell phone, we can have many tens or hundreds of teams whose work must all come together to create a marketable device. Trying to put the PBIs from all of these teams into one manageable product backlog isn’t practical (or necessary).

To begin with, not all of these teams work in related areas. For example, we might have seven teams that work on the audiovisual player for the phone, and another eight teams that work on the web browser for the phone. Each of these areas delivers identifiable value to the customer, and the work in each area can be organized and prioritized at a detail level somewhat independent of the other areas. Based on these characteristics, most organizations address the large-product problem by creating hierarchical backlogs (see Figure 6.14).

At the top of the hierarchy we still have the one product backlog that describes and prioritizes the large-scale features (perhaps epics) of the product. There would also be one chief product owner, as I will discuss in Chapter 9, at this level. Each of the related feature areas then has its own backlog. So the audiovisual player area has a backlog that contains the PBIs for the seven teams that work in that area. The PBIs at the feature-area level will likely be smaller in scale (feature or story size) than the corresponding items in the product backlog. In Chapter 12 I will discuss the release train concept that is based on a three-level enterprise backlog model: the portfolio backlog (containing epics), the program backlog (containing features), and the team backlogs (containing sprintable user stories).

Answer 3

I've seen team-specific backlogs work well where multiple teams have been working on distinct areas of a very large application. The fact that it got that large in the first place is more of an issue for software architecture, so shouldn't be an immediate concern.

However, that does also encourage silos..those teams know the areas of the product that on which they work, and no others. Defects can be a good way of introducing teams to new areas of the product, or, moving team members around so that they experience other aspects of the product and you evolve into a wider team who can pick up anything.