(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?
In the industry, a ‘backlog’ usually refers to all the tasks added over time that your team never found time to work on.
This backlog, then, usually contains:
- Old tech debt tasks
- Low priority bugs
- Feature requests that were never prioritized
Backlogs tend to grow over time because teams have limited capacity, while stakeholders always want more than the team can deliver. Thus, maintaining backlogs often 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 accumulate this pile of work items over the years and then, when it’s no longer maintainable, you add a maintenance procedure. Or, in my view: you created a monster and now you need to feed it.
Why create the monster in the first place?
What do I suggest instead?
I don’t maintain backlogs in the traditional way.
I work according to the CAF Product Framework described here.
As I’ve said several times in the past – If you follow this framework, your life will become much simpler, the chaos will be gone, and you won’t need to maintain a pile of junk.
Now practically, when it comes to backlog:
If you’re working according to this pyramid, then you have a roadmap and a quarterly plan. That’s your backlog. Why would you need anything else?
Common reaction I get:
“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 these items were truly important – meaning they create a true impact on business KPIs and promote your strategy – they would have been worked on by now, or at least included in your quarterly plan.
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:
As a working assumption – I assume that any feature/bug/tech debt item that wasn’t brought up in the last quarter is probably not very important.
Because if it’s really important – even if it’s an old item – someone would wake up at some point in the last 3 months and ask you (at least once) – “Dude… when can we finally promote this item?”.
If nobody did so – then nobody cares about this item.
Based on this assumption I maintain a short term backlog. It only contains items that didn’t make the cut for my quarterly plan, and someone asked for them sometime within the last quarter.
When a new quarter begins, I apply the following decision flow:
- Delete all items not mentioned in the last three months.
- Consider whether any feature request or bug from this pile should make it to the quarterly plan. If so, it becomes a candidate for the upcoming plan.
Is This Too Aggressive? Am I losing valuable knowledge?
I don’t think so. Here is how the alternative approach looks:
- You own a huge database of petty 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.
From my experience, the fact that a product manager can allocate time to such a ritual usually hints that he or she doesn’t have a proper strategy, nor an impactful roadmap. Because if they did – it was very clear to them what are features or capabilities that they need to work on and that will have a significant impact on their business – rather than looking for hints in the trash can.
To summarize
If you maintain a huge backlog, you’re probably doing something wrong. Replace it with a proper north star, strategy, roadmap, and a quarterly plan, and your life will be much better.
—
If you have any feedback on this post – feel free to write me and let me know what it is. I’d be delighted to hear from you.
If you think your friends/peers can enjoy this newsletter as well – invite them to subscribe on this page.