Picture by Imani Clovis, published on Unsplash under the Creative Commons Zero license

The Product Backlog Board

Published on 7th March 2011

Are you struggling with your product backlog? Then try my Product Backlog Board, a structured hierarchical product backlog that helps make sure you have ready items, capture non-functional requirements, and integrate your requirement models.

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.


A Multidimensional, Nonlinear Product Backlog

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. I have therefore started to work with a multidimensional and nonlinear product backlog, which I call “Product Backlog Board.” Here is a sample product backlog board:

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.
  • 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 mockups 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. On distributed projects, you can easily 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 roadmap and to focus its content on the items that are essential to develop the next product version or the next major 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.

Post a Comment or Ask a Question

18 Comments

  • Tamas Rakoczy says:

    Great! I’m going to try this.

  • Arun Patnaik says:

    Hi,

    This is a great idea to make things simple. This will make Product management decisions to be aligned properly.

    • Roman Pichler Roman Pichler says:

      Thanks for the feedback, Arun. Glad you find the product backlog board helpful.

  • Chris Sterling says:

    Hello Roman,

    Great post! We use something similar that is between a user story map and the board idea above. We may be able to pull more of what you discussed and add value to our AgileEVM product backlog. Thanks!

    BTW. For the constraints portion, you might find the survey for software quality attributes tool helpful for teams and product folks to get on same page about these constraints and their importance:

    http://www.gettingagile.com/2009/05/17/survey-for-software-quality-attributes-where-should-we-focus/

  • Arran Hartgroves says:

    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).

    Cheers, Arran

    • Roman Pichler Roman Pichler says:

      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.

  • James Scrimshire says:

    Hey Roman

    Your timing is fantastic, just when I needed a fresh approach to help my product owner gain a better understanding of what the team need from him, up you pop with this great tool.

    The tweak we’ve made is the team decided when stories are ready and can be moved into the ready box. Already seeing some results in terms of better story clarity.

    • Roman Pichler Roman Pichler says:

      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: https://www.romanpichler.com/blog/grooming-the-product-backlog/

  • Chris Chan says:

    Nice!

    What are you thoughts of adding the Vision Statement and Roadmap to complete the picture? They don’t take much space and possible can go right along the top of the Board.

    • Roman Pichler Roman Pichler says:

      Hi Chris, Great suggestion. So far I’ve put up the product vision and roadmap next to the board as separate artefacts. But I’ll try out your idea!

  • Roger L. Cauvin says:

    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.

    • Roman Pichler Roman Pichler says:

      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.

  • Terry Bunio says:

    Excellent article. The absence of non-functional requirements and models is something I also was struggling with.

    Cheers,

  • Dave Nicolette says:

    Nice. Could have a risk mitigation area too, if appropriate.

    • Roman Pichler Roman Pichler says:

      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.

  • Søren Cosmus says:

    Great tip. I’ll try it out with my Product Owner team at YouSee.dk

  • Mike Cohn says:

    I think this is great, Roman. Thanks for sharing it.

  • Agile Scout says:

    Love this! Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.