The Good, the Bad, and the Ugly Backlog

Published on 6th March 2013

The product backlog is an important tool: It lists the ideas and requirements necessary to create a product. But is it always the right tool to use? This post discusses the strengths of a traditional product backlog together with its limitations. It provides advice on when to use the backlog, and when other tools may be better suited.

The Good

The product backlog lists the outstanding work necessary to create a product. This includes ideas and requirements, architectural refactoring work, and defects. The good thing about a list is that it requires prioritisation decisions: The product owner has to decide when an item should be implemented.

Prioritisation provides direction to the team, and it supports sprint planning: The backlog items are not only ordered from top to bottom, but they are detailed according to their priority. The items at the top should be small and ready for the next sprint. Having the backlog prioritised makes it also possible to carry out release planning: It helps anticipate when an item is likely to be delivered (using a tool like the release burndown chart).

The Bad

Working with a list is helpful when the focus is on adding functionality, on writing and prioritising user stories. But creating a great product requires more than just user stories. The user journeys, the visual design, and the nonfunctional properties have to be considered too. Unfortunately, they don’t fit into a list.

As a consequence, agile teams either forget about capturing the user experience, or they keep the UX artefacts separately, for instance, on a wiki page, or in a project management tool. While the former can result in a product with a poor user experience, the latter isn’t great either: information that belongs together is stored separately. This makes it more difficult to keep the various artefacts in sync, and it can cause inconsistencies and errors.

The Ugly

I have seen quite a few ugly product backlogs: disguised requirements specifications copied into an Excel spreadsheet, JIRA backlogs that made it impossible to find the right user story, and backlogs with five loosely related epics scribbled on paper cards and carelessly stuck on the office wall. While the product backlog is hardly to blame for this, its list-based nature does not always provide teams with the support they need, particularly for creating a new product.


A traditional, linear product backlog works best when the personas, the user interaction, the user interface design, and the operational qualities are known, and don’t not have to be stated. This is usually the case for incremental product updates. For new products and major updates, however, I find that a traditional product backlog can be limiting, and I prefer to use my Product Canvas.

No single tool fits all needs and excels in all scenarios. Choose your tool to capture ideas and requirements wisely, and use the degree of innovation present in you product to select the right one.

This post was last updated on 28 January 2014.

Post a Comment or Ask a Question


  • Sebastien Sacard says:

    “includes ideas and requirements, architectural refactoring work, and defects”… Really ? The backlog should not contain ideas or technical tasks.

    Regarding new products or major new releases involving UX makeover : the solution is to start the Product Disvovery phase upfront, at least 2 sprints before, and this work is led by UX people.

    Then the Product development phase can start, with a nice backlog.

    • Roman Pichler Roman Pichler says:

      Hi Sebastien,

      You have to decide for yourself which items you want to include in your product backlog. But the original definition of the backlog in Agile Software Development with Scrum states on pp. 32: “Product Backlog is an evolving, prioritized queue of business and technical functionality that needs to be developed into a system,” and “Anything that represents work to be done is included in Product Backlog (sic)”.

      If a discovery phase works for you then that’s great. I prefer to work with a series of experiments/iterations, particularly for new products and major updates. You can find out more about my thoughts here: and

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.