Most product backlogs I have come across either contain too much or too little information, ranging from literally a handful of user stories to many hundred items. Many backlogs don’t consider non-functional requirements and do not provide high priority items that are “ready” – clear, testable and feasible.
How come product owners and teams struggle to use the product backlog effectively? One of the reasons lies in the linear nature of a traditional product backlog: It is a list of “features, functions, technologies, enhancements, and bug fixes,” as “Agile Software Development with Scrum” states. Such a list works well for creating a simple product. But it can be inappropriate for a more ambitious one.
Overview of the Product Backlog Board
I have started to work with a structured and hierarchical product backlog, which I have named “Product Backlog Board.” Here is a sample product backlog board:
Figure 1: The Product Backlog Board
The product backlog board depicted in Figure 1 provides the following elements
- A prioritized story area with a ready section, and a section containing themes and their epics.
- A constraint area with the global operational qualities and the critical product design and user interface requirements.
- An optional model area that provides requirement models.
I am not the first person to recognize that flat product backlogs can be inappropriate; Jeff Patton did so a few years ago when he developed his story maps, for instance. You could even use a story map within the story area of your product backlog board if you wanted.
Comments