In Lord of the Rings, Dark Lord Sauron forged one ring to rule them all from the volcanic fires of Mount Doom. There were other rings but none had the same power as Sauron’s malevolent band of gold. He realised the importance of a single source of power.

In many ways, a product backlog is similar. It should be the single source of all information. It should be a container for everything that you intend to deliver. Don’t keep different lists for different things. That just makes everything so much more complicated and difficult to find.

A backlog is not fixed. It will change over time as new requirements emerge. Equally, just because something exists on your backlog does not mean that it will actually be delivered. It’s simply a list of things to do – product backlog items (PBIs), in priority order, at any given time. Whether you use a dedicated tool or post-its and a wall makes no difference. As long as it works for your team, it’s ok.

For large scale development, you can use views to filter the product backlog for different areas and teams. In this  way, teams can focus on their own commitments whilst still keeping everything in one place. You need to be careful with the relative sizing of product backlog items if that’s how you estimate them. But that’s a story for another day.

A product backlog can contain features, bugs, technical requirements and spikes amongst other things. A simple status will allow you to distinguish between different types of PBI. The next time you find separate lists for bugs, features or whatever, consider moving them all into a single backlog. Because the best ideas are often the simplest.

 

Store everything in a single product backlog. Use views to filter data by areas, teams and  types of backlog item.