Pruning our product backlog

He who travels light, goes far.

                 -- Chinese proverb

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
• Product ideas

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:

1. Brutally delete or archive our entire backlog
2. 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:

1. Setup a rule
   
   
2. Go through the stories one by one
3. Analyze the result

What is the outcome?

We noticed 3 main anti-patterns for user stories in our backlog:

1. 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
2. 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
3. No useful information: Stories captured without a value statement, use cases or customer flags provide us with very little value.

What we learned

1. 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
2. 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.”
3. 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?