The Good, the Bad, and the Ugly Backlog

The product backlog is an important tool: It lists ideas, requirements, and new insights. 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

A traditional product backlog lists the outstanding work necessary to create a product. This includes ideas and requirements, architectural refactoring work, and defects. I find its greatest strength its simplicity, which makes it incredibly flexible to use: Teams can work with the product
 
backlog in the way that’s best for their product. Items can be described as user stories or as use cases, for instance, and different prioritisation techniques can be applied. This flexibility makes it possible to use the backlog for a wide range of products, from mobile apps to mainframe systems. The second great benefit is the backlog’s ability to support sprint and release planning. This is achieved by ordering its items from top to bottom, and by detailing the items according to their priority. Small, detailed, and prioritised items at the top are the right input for the sprint planning meeting. Having the reminder of the backlog ordered makes it possible to anticipate when the items are likely to be delivered (if a release burndown chart is also used).

The Bad

While simplicity is its greatest strengths, I also find it a weakness: Personas to capture the users and customers with their needs don’t fit into a list, nor do scenarios and storyboards. The same is true for the user interface design, and operational qualities such performance or interoperability. As a consequence, these artefacts are kept separately, for instance, on a wiki or in a project management tool, or they are overlooked in my experience. While the latter can be very problematic, the former isn’t great either: information that belongs together is stored separately. This makes it more difficult to keep the various artefacts in synch, and it can cause inconsistencies and errors.

Similarly, working with a product backlog that consists of a list makes sense when release planning is feasible and desirable. For brand-new products and major product updates, however, the backlog items have to emerge: Some will be missing initially and are discovered through stakeholder feedback, others are too sketchy or are likely to change significantly. To make things worse, a team working on a new product may not be able to estimate all product backlog items at the outset, as the team members may have to find out how to best implement the software.

The Ugly

I have seen quite a few ugly product backlogs in my work including disguised requirements specifications with too much detail, long wish lists containing many hundred items, and “dessert backlogs” consisting only of a handful of loosely related stories. While that’s not the fault of the product backlog, I believe that its simplicity does not always give teams the support they need, particularly when a new product is developed.

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. (But the canvas would most likely be an overkill for an incremental product update or a maintenance release!)
 

Reference: The Good, the Bad, and the Ugly Backlog from our JCG partner Roman Pichler at the Pichler’s blog blog.

Source : feedproxy[dot]google[dot]com