The Product Backlog Board

Posted on Monday 7th March 2011

Summary

Are you struggling with your product backlog? Then try Roman’s 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.

11 Flares Filament.io 11 Flares ×

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

43 comments on “The Product Backlog Board

  1. Agile Scout says:

    Love this! Thanks!

  2. Mike Cohn says:

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

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

  4. Dave Nicolette says:

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

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

  5. Terry Bunio says:

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

    Cheers,

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

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

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

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

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

  10. 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/

  11. Samantha says:

    Hi,

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

    http://www.inevitable.co.za/2011/03/releasebacklog/

    Thanks
    Sam

  12. [...] few weeks ago I read this blog post by Roman Pichler and decided to try some out-the-box thinking with regards to our release planning. [...]

  13. [...] Scrum-Trainer Roman Pichler macht einen Vorschlag, wie das Product Backlog und Bedingungen („Constraints“) besser visualisiert werden können: The Product Backlog Board [...]

  14. [...] „All Things Product Owner“ von Roman Pichler: Der Scrumtrainer und mehrfache Buchautor schreibt regelmäßig und überzeugt durch tolle Anregungen, wie die zu einem Product Backlog Board. [...]

  15. [...] 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. [...]

  16. [...] post presents a structured and hierarchical product backlog board that considers non-functional requirements and display high priority items that are ready to [...]

  17. [...] few weeks ago I read this blog post by Roman Pichler and decided to try some out-the-box thinking with regards to our release [...]

  18. [...] 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. [...]

  19. Synesthesia says:

    [...] The Product Backlog Board [...]

  20. [...] Woche habe ich mit meinem Team einmal über das Product Backlog Board nach Empfehlung von Roman Pichler gesprochen. Das Product Backlog Board ist eine Visualisierung des Product Backlogs und der [...]

  21. [...] few weeks ago I read this blog post by Roman Pichler and decided to try some out-the-box thinking with regards to our release planning. [...]

  22. [...] grundlegenden Aufbau eines Backlog Boards erläutert Roman Pichler in seinem Artikel The Product Backlog Board. Die folgende Darstellung zeigt ein reduziertes Board, an dem auch wir uns orientieren: Das [...]

  23. [...] 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 [...]

  24. [...] Make your sketch visible and put it on the product backlog board as shown [...]

  25. [...] in the image above, the product backlog board’s top section is empty, as the high-priority items have been consumed [...]

  26. [...] prefer to work with my Product Backlog Board, a structured, multi-dimensional backlog that contains three areas [...]

  27. [...] important to ensure that there are enough ready items on the product backlog. Consequently, my product backlog board uses a subsection in the story area [...]

  28. [...] THE PRODUCT BACKLOG BOARD von Roman Pichler (Neu 06.05.2012) [...]

  29. Arun Patnaik says:

    Hi,

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

  30. [...] a product roadmap can benefit your product backlog [...]

  31. [...] Product Backlog Board to facilitate the development of an innovative product [...]

  32. [...] The canvas has grown out of my work with product owners and product managers over the last ten years, and it is based on its predecessor, the Product Backlog Board. [...]

  33. Great! I’m going to try this.

  34. [...] few weeks ago I read this blog post by Roman Pichler and decided to try some out-the-box thinking with regards to our release [...]

  35. [...] “All Things Product Owner” von Roman Pichler: Der Scrumtrainer und mehrfache Buchautor schreibt regelmäßig und überzeugt durch tolle Anregungen, wie die zu einem Product Backlog Board. [...]

  36. [...] completo, e incluso para cualquier interviniente, sobre la cual leí por primera vez en el blog de Roman Pitchler , y es lo que llama el Backlog [...]

Leave a Reply

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

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>