Backlog? We don't Need No St%#$g Backlog!
On aggressive backlog management
(If you didn’t get the title - see reference here)
If you are working according to Scrum methodology then you are probably familiar with the concept of ‘Scrum Grooming’.
According to the ‘Scrum Institute’ - the definition of Scrum Grooming is (see here):
“Scrum Backlog Refinement (Grooming) Meetings aim to keep the Product Backlog up to date.”
They then explain what it practically means:
“During Scrum Backlog Refinement (Grooming) meetings, the participants fine-tune the Product Backlog with the following actions:
Add new user stories based on newly discovered requirements.
Remove user stories which are no longer required for the product.
Fine-tune estimates of user stories.
Update priorities of user stories.
Split giant user stories into digestible smaller user stories, and prioritize them accordingly.”
Let me give you my TL;DR take on this ‘grooming’ and backlog management thing -
Such a waste of time.
Here is the full version on my take on this:
What is your backlog really?
When referring to ‘backlog’ the industry usually refers to all of the tasks that were added over time, and your team never found the time to work on them.
This backlog, then, usually contains:
Old tech debt tasks
Low priority bugs
Feature requests that were never prioritized
Backlogs tend to grow and grow over time, as the team always has a certain capacity and the various stakeholders (internal and external) always want more than the team can deliver. Thus, over time, going through backlogs and maintaining them to be ‘in order’ becomes a task of its own.
My take on backlogs
To me - backlogs are just a pile of junk.
Yes… sorry. Junk.
I have no other word to describe it.
Look, you grow this pile of junk over the years and then, when it’s no longer maintainable - you add to your routine a maintenance procedure.
Or, in other words, and this is how I see it: you created a monster and now you need to feed it.
Why create the monster in the first place??
Ok… so what do you suggest instead?
I don’t maintain backlogs. At least not in the traditional way.
I work according to the pyramid described here.
I keep sending you back to the same post over and over again, because if you’ll work according to this - your life will become much simpler, the chaos will be gone, and yes - you won’t need to maintain a pile of junk.
The post linked above encompasses about 70% of the knowledge on how product managers should work (and organizations in general). When in doubt - just revisit it.
Now practically, when it comes to backlog:
If you’re working according to this pyramid - then you have a roadmap and you have a quarterly plan. That’s your backlog.
Why would you need anything else?
The main reaction I receive from people who are shocked that I don’t maintain backlogs is usually:
“Wait… but the backlog contains some important items. It contains important documentation of what you should do next.”
Really?
Let’s revisit what the backlog contains:
Old tech debt tasks
Low priority bugs
Feature requests that were never prioritized
My philosophy is simple:
If those items were important, and by important I mean - moving the needle and promoting your strategy and north star - then you probably would have worked on them by now, right?
The fact that they keep being postponed means they are not important enough. So why revisit them again each and every time?
Instead I use a different approach:
First, I separate feature requests from the bugs and tech debt items. Each is being handled differently as described below.
Feature requests
I manage feature requests in a simple spreadsheet. I make sure each feature request is described in not more than 2 sentences. A tagline.
I maintain a counter for each request, and a column of ‘who asked for it’, since not all customers were born the same.
Last - I maintain a column of ‘when it was last asked’.
Each time I receive a new request I try to map it to an existing record.
Usually feature requests are phrased differently by each stakeholder and someone needs to understand that requests which are phrased differently are actually referring to the same pain. I care much more about pains than I care about specific solutions (why? See here).
Hence, I map all requests which are mapped to the same pain to the same row.
Now, maybe with the rise of ChatGPT the mapping process can be done automatically, I don’t know. It’s a nice initiative. But until it happens this mapping can only be done by a product manager. Any attempt to let the various stakeholders match their requests to existing requests will most likely fail (they are too lazy, or simply don’t understand how to spot the pain behind the request).
Now, here is the twist - at the beginning of each quarter - I remove all feature requests which weren’t ‘echoed’ at all in the last quarter. The logic is simple - if nobody asked for it in the last quarter - it probably doesn’t matter or it’s no longer relevant. This is how I make sure the spreadsheet is light, compact and includes only items we care about.
Bugs & tech debt
Those items follow the same logic, except they are probably managed in your tasks management tool (Jira, Monday or whatever). They are also probably more detailed than the feature requests I mentioned before.
Most of the time I don’t even bother to actively clean them. The engineering team usually wakes up one day and complains to me that the Jira is a mess and needs to be cleaned up.
I simply ask them to send me all the tickets that have been lying there for a while. They send me this list and I simply close all of them with no mercy (again, those which nobody has inspected or asked about for more than a quarter).
This is too aggressive. You are losing valuable knowledge.
Am I?
Think about it for a while. REALLY think about it. Think about what you are doing:
You are maintaining a huge database of penny items that nobody asks for or about for more than a quarter.
Those items are clearly not moving the needle or will push your north star dramatically forward. They are also not important enough to cause significant churn with any customer (otherwise, someone would bring them up during the quarter).
Now, because you are holding to this huge pile of junk - you need to maintain it. So, from time to time - you voluntarily allocate time to dig through this pile of junk and look for gems. Let me tell you a secret: You won’t find any.
And the fact that you are allocating time to dig through a pile of junk strongly hints that you don’t have a proper strategy, nor a roadmap. Because if you did - it was very clear to you what are features or capabilities that you need to work on and that will have a significant impact on your business - at any point in time.
To summarize
To be honest, this post is quite straightforward so I’m not sure I need to summarize it. But here is the short version:
If you maintain a huge backlog you are probably doing something wrong. Just replace it with a proper north star, strategy, roadmap and a quarterly plan and your life will be much better.
That’s it for today.
If you have any ideas for posts or topics you want me to cover - PLEASE LET ME KNOW.
If you found this post/series useful - feel free to ‘like’ it. If you think others can benefit from it - feel free to share it with them.
Thank you, and until next time :-)