BT

Do we need an alternative to the product backlog?

by Anand Vishwanath on Aug 17, 2012 |

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 ?

 

Hello stranger!

You need to Register an InfoQ account or 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

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT