The Good, the Bad, and the Ugly Backlog

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.

---

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.