About Roman Pichler

Roman is an agile product management expert. He helps companies create new products by providing consulting and training services, and he is the founder of Pichler Consulting.

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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


eight × = 56



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close