Why SCRUM Backlogs lead to bad Product Decisions
I used to be a huge fan of SCRUM sprints and backlogs when it comes to planning software projects but the more I dive into product management the more I view them as anti-patterns that lead to bad product decisions.
What’s a Backlog?
In theory a product backlog is a list of requirements that you’ve committed to implement. As simple as that.
The product backlog is a […] list of requirements that […] need to be done in order to successfully deliver a viable product.
— Wikipedia
For most software teams the product backlog is the manifestation of what gets built next. This works well as long as you manage to keep the backlog well groomed and manage to keep everything out that doesn’t belong there.
The Backlog easily turns into an “Everything Bucket”
In reality though it is really difficult to protect the product backlog in that spirit. I’d even argue it is impossible. It’s way too tempting to put everything into the backlog that sounds like a great idea which you don’t want to forget about.
Other times adding a feature request to the product backlog is the only way to keep pushy stakeholders happy without actually having to add the feature to the product immediately.
Most backlogs I’ve seen feel more like “everything buckets” or pools of ideas & inspirations than actual requirements that are essential to the product’s success.
The following two tweets by Stephan Schmidt really capture the essence of how I feel about backlogs.
I think in a time where we can ship new versions of our software almost immediately it is time to really embrace just-in-time concepts.
Committing to granular work items way before you even get to implement them doesn’t make much sense anymore.
Early decisions often result in work that has to be thrown away. Even worse, those early decisions can have crippling and unavoidable consequences for the entire future of the project.
— Jeff Atwood
If you still use a backlog I’d only fill it with epics or high-level themes.
But I think there’s an even better way than that.
Replacing the Backlog with a Product Strategy Roadmap
At Blossom we’ve completely replaced our product backlog with a free form Google Docs file. It reads more like a marketing document than a traditional backlog. We call it our product strategy roadmap. In this file we’ve defined a few simple things on top …
- What are our customers hiring our product for?
Source: A super useful concept by Clay Christensen.
(h/t for the pointer Eoghan McCabe & Des Traynor of Intercom) - What kind of super powers can we give our customers?
Source: A fantastic talk about product management by Kathy Sierra
Then the body of the document consists of high level (strategic) marketing-esque announcements of (future) product improvements. Similar to what you would read in a blog post when a company like Facebook, Apple or Twitter releases a new major feature.
The interesting thing here is that these announcements focus on the benefits and the intention of where we want to take the product and what’s in it for our customers.
It’s not a descriptions of features. It’s a higher level announcement text that helps to put features and other product changes into context.
I really prefer this format to a traditional backlog as it focuses on the customer benefits and is therefore easy to share with all stakeholders.
It also reminds us about what to focus on with product decisions. It is less about having a lot of ideas and more about telling a story and being great at editing what gets in and what is consciously left out.
Pulling from the Roadmap
Then every time space on our product board frees up we take a look at our roadmap document and pick something from it to pull into our process.
This might be a full ‘announcement’ at once or more often just a subset of an announcement that we then work on step by step.
The main advantage here is that we have a strategic document that’s clear and concise but at the same time very easy to change. It is very high level and mainly there to provide context for what a great execution of the strategy might be.
We don’t start with specifying implementation details until we’ve actually started to work on an item. This saves a lot of time and resources that we used to spend on doing backlog estimates, re-prioritizations and groomings in the past.
What’s your take on product backlogs? How do you handle them?
