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
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
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
Conclusion
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
2 Comments
“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.
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: http://bit.ly/OgERPI and http://bit.ly/QTHSEd