Do we need an alternative to the product backlog?

| by Anand Vishwanath Follow 0 Followers on Aug 17, 2012. Estimated reading time: 1 minute |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

A product backlog left unattended can become large and unmaintainable.  The common approach is to regularly review the backlog and throw away items that the team will never get to.  Neil Killick on the other hand questions the effectiveness of this very approach towards managing requirements itself.

According to Neil

  • It thwarts innovation
  • It compromises the holistic vision of the product
  • It creates a “requirements black hole”
  • It causes a maintenance overhead (cost, inefficiency)
  • Large queue = high cycle times
  • It makes it difficult for the PO to understand dependencies
  • It trivialises role of PO to one of ordering/prioritization

Neil provides further details on how this approach thwarts innovation

A problem with this approach is the same problem that one has when building a product based on up-front specification documents – it is not promoting innovation in the product’s evolution. If things are on the backlog then it seems a reasonable assumption that someone has put some thought and time into why that thing should be on the backlog, so there is a tendency (for the PO and team) to want to build the product “as is” and not upset the apple cart too much.

 Many companies plan 4, 5, 6 or more iterations in advance, lining up the “stories” to be done in those iterations and completely skip the innovation part


Todd Charron highlights the popular anti-pattern of looking for a sophisticated agile product management tool when the backlog becomes unmanageable. He instead stresses on the fact that


You don’t need a better backlog management tool, you need a smaller backlog


Roman Pichler talks about the dynamic nature of a product backlog and how it should be used as a learning tool instead of it being rigid and fixed.


We should therefore treat the items of an initial product backlog as assumptions that have to be validated and refined using the feedback from customers and users. 


Roman also provides several techniques in grooming a product backlog, one of them being the product canvas.  Have you noticed similar issues with your product backlog? What alternative approaches have you tried out ?


Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Symptom of larger problem? by Dave Nicolette

The issues noted sound like they might support a general observation that many organizations don't do a great job of connecting their strategic plan with their IT portfolios, and hence to the various product backlogs that support initiatives in the portfolio. It seems this could lead to the practice of discarding items merely because it seems unlikely a team will get around to them, rather than re-prioritizing planned work based on business considerations.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you