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.
The Story Area
The story area is divided into two sections: items that are likely to be worked on in the next sprint, and the other outstanding work that is essential to create a successful product. The items in the ready section must be clear, feasible and testable. They are preferably captured as small and detailed user stories with well-written acceptance criteria. The epics, however, are coarse-grained and sketchy. They are placeholders for future detailed stories, which are progressively derived from them. I find it useful to group related epics into themes. You can think of a theme as a product capability or goal, an epic as a feature, and a story as a function.
The stories in the ready section must be strictly prioritized - from one to n - to create focus and direct the work of the team. You don't have to order the themes and epics unless you want to indicate when functionality will be released, for instance, in form of an early product increment (beta). But don’t forget to review the epics on a regular basis, and consider risk and uncertainty as well as dependencies. This will help you to decide how to stock the ready section and to determine which stories have to be carved out of your epics.
The Constraint Area
This area contains the global non-functional requirements of the product: operational qualities as well as product design and user interface requirements that apply to the entire product. It's important not to neglect these constraints: They influence the user experience, drive architecture and the technology decisions, impact the total cost of ownership and the product's life expectancy.
I prefer to capture operational qualities using constraint cards. The critical aspects of product and user interface design are best described visually as sketches or screenshots of mock-ups and prototypes. Note that the items in the constraint area are not estimated. Instead, the definition of done states that all constraints must be fulfilled.
The Model Area
Workflows and models don't fit into a linear, flat product backlog. Consequently, many Scrum teams ignore them. While requirements modeling should be applied lightly in an agile context, teams often benefit from connecting individual stories and epics, for instance, by exploring how the various user roles interact with the key epics. The same is true for workflows: It's often helpful to look at a user story sequence to understand how a user interacts with the product and to explore the resulting user experience.
If requirement models and workflows are helpful to develop your product, then add a model area to the product backlog board. The models and workflows are neither estimated, nor included in the definition of done, as they simply elaborate stories and epics.
Making the Information Visible and Accessible
The product backlog should be visible and easily accessible for everyone involved in the development effort. I hence prefer to work with a physical product backlog board - paper cards and paper sheets put up on a large board or an office wall.
Figure 2: The Product Backlog Board on an Office Wall
If you work on a distributed project, then store the product backlog board as an electronic spreadsheet. Just remember to make it visible, for instance, by posting it on the project wiki.
Stocking the Product Backlog Board
I prefer to derive the contents of the product backlog board from the product vision or the product roadmap, and to focus its content on the items that are essential to develop the next product version. This reduces complexity, creates focus, and avoids predicting an uncertain future.
When you stock the constraint area, resist the temptation to create the complete product and user interface design upfront. Rather focus on those aspects that significantly influence the success of the product and that are difficult to change at a later stage. The detailed design should evolve from sprint to sprint based on customer and user feedback.
Summary
The product backlog board is a handy tool to capture and manage requirements. Its advantages over a traditional, flat product backlog include:
-
It facilitates emergence and minimizes the amount of detailed requirements by using epics and themes.
-
The board reminds the product owner and team to identify global non-functional requirements and it provides a place to capture them.
-
It allows integrating requirement models into the product backlog.
As the proof is in the pudding, try the product backlog board for yourself, and let me know how you are getting on!
Author: Roman Pichler
If you enjoyed reading this article, you will love Roman's book Agile Product Management with Scrum: Creating Products that Customers Love: http://www.amazon.com/Agile-Product-Management-Scrum-Development/dp/0321605780 and his agile product management blog: http://www.allthingsproductowner.com
© 2010 Roman Pichler, romanpichler.com