Most product backlogs I have come across either contain too much or too little information, ranging from literally a handful of user stories to hundreds of items. Many backlogs don’t consider nonfunctional requirements and do not provide high priority items that are “ready”—clear, testable, and feasible.

Why do product owners and teams struggle to use the product backlog effectively? The linear nature of a traditional product backlog is one reason.  As Ken Schwaber states in his book, Agile Software Development with Scrum [1], the product backlog is a list of “features, functions, technologies, enhancements, and bug fixes.” 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.”

Figure 1: The product backlog board

The product backlog board depicted in figure 1 provides 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, and 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 the 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 nonfunctional 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, and 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. Hence, I 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, by posting it on the project wiki, for instance.

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.

Conclusion
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, it reminds the product owner and team to identify global nonfunctional requirements and it provides a place to capture them, and it allows integrating requirement models into the product backlog.

As the proof of the pudding is in the eating, try the product backlog board for yourself, and let me know how you are getting on!

References

[1] Agile Software Development with Scrum: http://www.amazon.com/Agile-Software-Development-Scrum/dp/0130676349.

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

Trackback(0)

TrackBack URI for this entry

Comments (2)

...
written by Roman Pichler, August 26, 2011

Hi Matthias,

Thanks for your feedback.

ad 1:
Jeff Patton's Story Maps in an alternative non-linear product backlog that seems to work best when requirements are collected bottom-up and then the essential features (the backbone) are selected. I prefer to work with a top-down approach and derive the requirements from the product vision (or product roadmap).

ad 2:
You can certainly colour-code or index stories and epics if you must track their relationship.

ad 3:
Stories that are done and have been accepted by the product owner are generally removed from the product backlog. If you want to record changes to your product backlog, I suggest you take pictures or version control your electronic backlog.

ad 4:
You can find my recommendations for user story modelling here: http://www.romanpichler.com/bl...modelling/

Roman

• 
• +0
• 
• 

...
written by Matthias Edinger, April 19, 2011

Hi Roman,
I like this article, but...
1.You mentioned the story maps from Jeff Patton. I miss somehow his idea in your Product Backlog Board. Again you cut the tree and put it in a non structured manner
2.The Ready Items part is a very good idea to make transparent which stories are elaborated good enough to implement. But again the link to the underlying Epic and Theme is lost. I would keep this and work e.g. with colors to keep this link.
3.What happens when stories are implemented? They vanish from the wall. But as a product manager I want to keep the complete picture of my product. So how to deal with this?
4.Model area: you mention that modeling should be applied lightly. I do agree and I have impression that at the end you will end with similar models you use for classical requirement engineering. My gut feeling tells me that if you want to work in a sustainable way you will need these models.
Best Regards,
Matthias

• 
• +0
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview