Fewer backlogs = more big picture optimization

How many backlogs should you have? As few as possible.

On one project I worked on, we had a backlog per team. This is an easy trap to fall into. It gives the team the ability to focus on their own part of the world with minimum interaction with the outside world. It gives the product owner of that team independent control over what they are doing.

The problem is that it results in local optimization. Sure, that team is doing the most important things within their scope, but these might not be the most important things in the bigger picture. The right answer may be that the team would add greater value by helping out in other areas.

This becomes obvious if you go to a single backlog and prioritize everything in it. Now you realize that the team is working on priority number 30, 35 and 39 while other teams are tackling items prioritized in the top 10.

One interesting aspect of this is that it encourages generalization across teams. Just as within an agile team you should strive to produce generalists, the same applies at the higher level as well. Doing so allows the team to do a better job of attacking the highest priority things, not just the things the people available are good at. It makes it easier for the team to be more flexible.

Another advantage of combining backlogs is that it promotes collaboration. The fact that you have to talk with others to work out the priorities is a good thing.

How far do you take this? Particularly for small companies, you could see a backlog whose scope is the entire company.

For bigger companies, this might become too big to deal with. So you potentially go with a multiple layer approach. You could have a high level backlog at the corporate level and this could feed into the more detailed backlogs at the lower level (ex., product line). One rule of thumb might be that if you're doing a Scrum Of Scrums together, you should probably have a common backlog.