Should We Get Rid Of The Product Backlog?
(first published on July 26th 2012, migrated from my deprecated Wordpress site)
What’s wrong with the Product Backlog?
Many companies and teams are using the idea of backlogs to help them evolve, visualise and order their portfolio of work. In terms of the work required to bring a particular product to fruition, the Product Backlog is often used in conjunction with an iterative development approach as an alternative to documenting a fixed set of requirements and a solution before development work is started.
However, the Product Backlog concept niggles me quite a bit and has actually proven in my experience to be a poisoned chalice in some respects. I actually now believe that constantly adding, removing and tailoring requirements (or stories, use cases, whatever) on the Product Backlog is (especially in the wrong hands) a fairly ineffective and costly approach to building software.
There are several reasons why I believe this to be so:
- 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/prioritisation
Thwarts innovation
A Product Backlog is supposed to be a list of things we might want in the product, ordered by value (value pertaining to importance, ROI or whatever the Product Owner deems to be worthy reasons to satisfy certain particular requirements as the next priority). However, what it often ends up becoming is a big long list of everything we (think we) need to build in the product. Aside from the fact it becomes increasingly difficult to maintain and make sense of this list, building the product becomes a ritual of ordering the backlog and the team building the top things from the backlog in iterations until the product is deemed ready to “go live”.
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. In short, the backlog becomes nothing more than a list of up-front requirements which may as well be in a BRD.
A truly iterative approach to building software allows requirements, design and architectural improvements to emerge as we go along. This sometimes means scrapping the whole thing and starting again. If we simply “work from the backlog” we may not pay the necessary attention to determining how best to evolve the product and instead go for the easy option of simply churning out the stuff already on the backlog.
In Scrum, the Sprint Review is intended as a meeting to review the evolution of the product and how it should be taken forward in the next Sprint. Many companies instead have a “Showcase” to demonstrate what has been achieved in the last 2 weeks. This approach completely negates the importance of feedback and putting our heads together to determine the best bang for our buck over the next 2 weeks, i.e. “reviewing” the product.
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.
Compromises holistic vision of product
For iterative development to work well we must continually evaluate the product as a whole, i.e. we must iterate and increment simultaneously. The Product Backlog does not promote this concept.
Again, there is a tendency when working with a list to just work through the list — to add purely incremental value rather than a holistic approach. This can lead to much re-work, delay and added cost, both from a product value and a technical/architectural point of view.
Requirements black-hole
The idea with the Product Backlog is that we can easily add new requirements to it and re-order things so that if a new opportunity emerges while we’re building the product we can easily prioritise that opportunity and deliver the value fast. In reality what happens is that stakeholders ask for features and the PO adds them to the backlog to keep them happy. This (rightly or wrongly) sets expectations. And with expectations come a whole barrage of politics. The problem here is that the PO can give no guarantees whatsoever that the feature being asked for will ever be built, i.e. the goal posts are moving. Thus the backlog becomes a “requirements black hole”. Do not under-estimate the negative effects of this in terms of trust among colleagues and meeting your goals.
A stakeholder once said to me “when I’m told my request is on the backlog I immediately know it will never be built”. This is often a reality, so is there a better way?
Maintenance overhead
Not only is the Product Backlog a potentially enormous list of stuff, it’s a list that needs to be constantly groomed, usually at least fortnightly, to ensure the highest value things are at the top. Whether you use a backlog management tool or index cards, this creates a significant maintenance overhead (inefficiency) for the PO and team (and potentially other stakeholders).
The backlog can quickly become the focus rather than the product itself, and as it continues to grow it becomes increasingly difficult to prioritise or focus on the highest value things to build.
Large queue = high cycle times
Every new requirement added to the Product Backlog increases the average cycle time to deliver functionality to the users. Having a large Product Backlog can adds weeks, months or (dare I say it) years to cycle times. Is it particularly “agile” to tell a stakeholder that it will take 6 months to deliver a piece of functionality that in effort terms is only a 2-week piece of work? This situation can arise if you let your backlog get out of hand. All the dead wood requirements sitting down the bottom that everyone has forgotten about (but is afraid to delete) are preventing you from being responsive to the market or attacking new high value opportunities.
This potentially means those features that could give you competitive edge in the market will be scrapped for being deemed to take too long to deliver.
Dependencies
A large Product Backlog inevitably creates dependencies among items. Innocently adding a requirement to the backlog can eventuate in a cascade of dependencies that can add months to a project. By glancing at the backlog, are these dependencies transparent? Generally, no. They are invisible to the naked eye and thus have far reaching implications for the PO when trying to effectively order the items on the backlog. It can be extremely frustrating for a PO when the highest value items — requirements that they have taken time, negotiation and effort to prioritise and move to the top of the list — move down the list because of technical or other dependencies.
Taking a more holistic approach to the product makes it easier to dissolve these dependencies.
Trivialises role of PO
The larger the Product Backlog, the more time the PO will need to spend ordering it. This means more prioritisation sessions, more cost-benefit analysis, more workshopping, more estimating in order to determine size for ROI purposes. Little wonder that Product Managers are reluctant to take on the Product Owner role.
The Product Backlog can potentially trivialise the PO role to one of ordering and prioritisation of work rather than concentrating on building the best possible product with which to penetrate the market or increase the value of the business.
So, what’s the alternative?
To my mind, and in my experience, the important things about a product rise to the surface if you are doing proper Just-In-Time planning. By using the Sprint Review and the Sprint Planning meetings properly, the team and PO can properly gauge the evolution of the product and what direction it needs to take next. Why is a Product Backlog required for this? If you can’t remember what needs to be done, it’s not important. If you can remember what needs to be done, you don’t need it on the backlog!
I have found an evolving product roadmap can much more effectively align stakeholder expectations with what’s actually being built. A roadmap is very clear, easily interpreted and gives interested parties the information they crave. In the Sprint Planning meetings, why not ask yourself “How should we take this product forward in the next 2 weeks, and what can we realistically achieve?”. This focuses everyone on what is achievable which helps with simplicity of design as well as focus on value. Then update the roadmap with the new or changed high level ideas emerging from this planning session, and the rough delivery timeframes. It is a mistake to just focus on the next increment of the product in each Sprint Planning meeting. Each iteration should be an opportunity to re-align everyone with the product vision and what the best approach for the next 2 weeks should be.
Conclusion
A Product Backlog done well should paint a picture of the product. It should tell the story of what you aim to achieve. You should be able to show the Product Backlog to someone completely uninvolved and they can gauge exactly what the purpose and vision of the product is. What innate user need it is meeting. The “why” of product development.
If your backlog is simply a long list of stuff that will most likely never be done, perhaps you can look at an alternative approach?
Thanks for reading! If you are looking for help with your software or product delivery, I provide agile coaching, public training (both theory and practical) up to executive management level, and more. As well as public events, I can also run training internally in your organisation for a massively reduced cost, so please ✍ get in touch.
