Please note that the product backlog board has been superseded by the Product Canvas, a new type of backlog designed for creating new products and for product updates aimed at new markets. It extends the backlog board and connects personas with the product features. Please see my post “The Product Canvas” for more information.

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 Schwaber and Beedle (2002) write. Such a list can work well for updating an existing product. But it is often insufficient for developing a new product.

Enter the Product Backlog Board

I have therefore started to work with a structured and hierarchical product backlog, which I have named “Product Backlog Board.” Here is a sample product backlog board:

The Product Backlog Board (click to enlarge)

The product backlog board depicted above provides the following elements:

A prioritised story area with a ready section and a section containing themes with their epics.

A constraint area with the global operational qualities and the critical product design and user interface requirements.

An optional model area that contains requirement models.

I am not the first person to recognise 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 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. Epics are grouped into themes with each theme representing a product capability.

The stories in the ready section must be strictly prioritised, from one to n, to focus 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 ideas that apply to the entire product. It’s important to recognise and address 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. (I discuss design in more detail in my post on Agile User Interface Design.)

The Model Area

Workflows and models don’t fit into a linear, flat product backlog. Consequently, many Scrum teams ignore them. While requirements modelling should be applied lightly in an agile context, teams often benefit from connecting individual stories and epics, for instance, by showing how the user roles interact with the 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. Like the constraint items, the models and workflows are not estimated. But they are also not included in the definition of done, as they simply elaborate stories and epics. (I describe user story sequences and workflows in more detail in my post on user story modelling.)

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.

The Product Backlog Board on an Office Wall

On distributed projects the product backlog board can be easily stored 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 board or the product roadmap and to focus its content on the items that are essential to develop the next product version or the next major public release. This reduces complexity, creates clarity, 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.

Hi Dave, Great point. If a risk mitigation area is helpful for your products and projects, just extend the board. But I would recommend to keep the board simple and to also consider risk when working on the stories and epics. If an epic has risk or uncertainty associated with it, carve a story out that encapsulates the risk and put them in the ready section.

l like it, too. I would eliminate the “operational qualities” section of the board, however, and instead capture the nonfunctional requirements as acceptance criteria attached to epics. I.e. what usability, reliability, scalability, etc. measurements would your team perform while testing each epic?

Nonfunctional requirements rarely apply globally to the system. For example, the reliability requirements for a critical epic should almost certainly be more stringent than for an ordinary epic. If you apply more than a handful of nonfunctional requirements globally to the system, it usually indicates you haven’t sufficiently understood or capture customer needs and priorities.

Hi Roger, Good idea to add operational qualities to the acceptance criteria. I often do this for local non-functional requirements, for instance, a performance constraint that applies only to a specific story. I agree that there are usually only a handful of global operational qualities for a product. But I find them so important that I want to make them explicit. I would also recommend to identify the global constraints during visioning.

Thanks a lot for your feedback and nice suggestion, James! I did not mention it in the blog post, but I like to work with collaborative grooming sessions. These allow the product owner and the team to work together on the product backlog and to jointly write detailed stories: http://www.romanpichler.com/blog/grooming-the-product-backlog/

Hi, I very much like this concept. Especially for global non functional requirements and ad-hoc modelling.

Regarding Vision and Roadmaps, I guess you could get around having those by only have essential stories for the next release on the board (as opposed to a vision which can be comprised of multiple releases?).

The thing I’m missing is a space to progress ready stories across a set of states or even break down stories into tasks (so they can be examined during stand ups to check impediments).

Thanks for the feedback, Arran. I like to work with a product vision or a product roadmap to capture the overarching goal of the new product or the new product version. I use a vision board to capture the product vision, and it’s on my todo list to blog about it.

I use a separate task board for the team uses to manage the tasks to separates the management of the requirements from the tasks, and to create focus for the team.

Your blog post inspired me to think differently about our story maps and try something new … I have linked to you image in this post – I hope that is ok?
If not – please let me know and I will remove it. The post will only go live tomorrow

[…] Use the product backlog to detail the vision and capture additional information. Display market research data such as personas and scenarios and project-specifc information including the project organisation and the release burndown chart separately. This will keep your vision board easy to understand and focused. […]

[…] To capture and explore the relationship between different stories, I have found it useful to complement user stories with lightweight models originally invented for use cases: context and activity diagrams. I also add important diagrams to the product backlog, as I explain in my post The Product Backlog Board. […]

[…] majority of your backlog items sketchy and coarse-grained. A great way to do this is to employ my product backlog board and to capture ideas as epics. Identify the epics that exhibit risk and uncertainty and select the […]