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 ?