Does this kind of conversation sound familiar to you?
Customer: I want abc, because xyz.
Product team: Sorry, we don’t have it now, but I’ll add it to our backlog.
This comes up for me frequently on the Mingle team. We carefully capture all requests and spend time to follow up on each one. However, with each request, the queue keeps getting bigger.
What comes into our backlog?
Everything that is not done or has been brought up in conversations comes to our product backlog, including:
Feature requests from our customers
Defects that are not urgent and need more analysis work
Pieces of work that got de-prioritized and pushed back out of the current release
Does this work?
After doing this for 4 years, we looked into the data about our backlog and saw the following:
Stories in total vs. stories completed
Yes! We have 2,835 items in the backlog. Prioritization of this queue is not practical at all. It has become a knowledge base for old ideas and the information density is very low because there is simply too much noise.
And another smell of this giant backlog is that we have to separate our technical tasks from this giant queue to make sure they aren’t missed.
What should we do?
We have 2 options:
Brutally delete or archive our entire backlog
Manually clean up the backlog
Either way would work for our team. In fact, we’re planning to do both - use a new workspace to capture high level objectives in backlog, and then manually go through our backlog to understand how to maintain a lean backlog.
I would like to focus on what I discovered during the manual clean up process. I started with 400 items in our backlog. Here is what I did:
Setup a rule
Go through the stories one by one
Analyze the result
What is the outcome?
We noticed 3 main anti-patterns for user stories in our backlog:
Stories broken down too early: These stories should be consolidated into one master story. For example:
Flag role as able to export project
Flag role as able to Excel import
Flag role as able to Excel export
Flag role as able to manage saved views
Flag role as able to delete cards
Flag user as able to create project
Flag role as being able to edit any cards
Implementation suggestions instead of business value: To achieve the same benefit to the customer, there could be many different implementation solutions. We should keep items in the backlog “implementation agnostic”. Doing this provides better context for prioritization and reduces duplicates. For example, thesetwo stories are aiming to solve the same problem:
Story A: Warn user if there are unsaved changes when leaving card edit mode
Story B: Automatically save "draft" of pages and cards
Story C: Have a save and continue option for page/card editing
No useful information: Stories captured without a value statement, use cases or customer flags provide us with very little value.
What we learned
Leave the task of breaking down work to the last responsible moment: We should document new features at a high level. Breaking them down before really planning to work on them is a smell of upfront design
Focus on value and always ask more to understand the “why” behind the request: For example, our community reply to a new feature request, “We haven't scheduled this yet, but would like to know how you would use this feature and why? How would it change the way you work? We'd be very interested in details about your process and context around this request.”
Take the “active time” into consideration: We dismissed stories that were silent (i.e. had no activity or changes) for more than 1 year. Depending on the nature of your project or product, you can the find your own threshold number. The key takeaway for us was to prune our backlog frequently to get rid of the “dead” ones.
This learning will not only help us to continue to prune our backlog, but more importantly help us to apply these guidelines to new backlog items to prevent waste at an early stage. After filtering out the noise, we will focus on fewer things that are really important.
How do you prune your product backlog?
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.