Many Backlogs for a Single Scrum Team

March 26, 2008 by Artem

One of the mandatory artifacts of the Scrum process is a Product Backlog. In its simplest form it is just a flat list of things to do, quite often even without the complexity estimates. Its power comes from the strict order of elements. Customer can call many requirements equally mandatory or must-have, but in the list there is no way to position two items equally high. As a result a team is able to see the clear focus and sense the current expected direction of the project. Product backlog is not static. It changes over time: coarse grained items from the bottom are divided into smaller stories as team comes closer to them, some items are removed and some are added basing on the increased understanding of the area, technology and the market. Still, at any given point of time well maintained product backlog is the primary tool for communicating the current best understanding of the project direction.

Multiple backlogs for a team

Several times I've seen the situation, when there is no single product backlog for a team, but there are several "area backlogs" from which the top part of a real product backlog is dynamically assembled before or even during the sprint planning. Naturally it happens more often in the situations, when one team has to develop several projects simultaneously or many teams do many projects.

While this approach can work and sometimes you just have to do it (for example, if there are highly specialized people in the team that just have to support and enhance "their" projects) it always creates some clumsiness. Product backlog is supposed to be dynamic indeed, however, it is also supposed to provide at least rough perspectives on the project future. Many different backlogs are not a simple direction anymore and generate something what product backlog was invented to solve - unclearness about the priorities. If product owner is not able to generate a single priority list, the team is also not able to perceive the real customer priorities.

While having multiple backlogs can make sense in some contexts, in general it is a good idea to try avoiding a multi-backlog situation. Especially if you are not yet familiar with Scrum and are just trying it. Multi-backlog as well as multi-site or multi-team situations can work effectively, however it is not exactly easy.

Your experience

What about your team and the teams around? Did you see teams working from several backlogs at once? How well does it work in your environment?

Permalink