Backlog Management Guide
From Nonsense to Value Creation
Backlog management is supposed to be simple, but the reality is different. Often, the backlog becomes a disguise for a waterfall framework.
The more items you have in your backlog, the more distant to agile you are.
The less goal-oriented your backlog is, the more fragmented your team becomes.
The more you focus on backlog management, the less you can discover value drivers.
Unfortunately, the backlog quickly deviates from a vehicle to create value to a distraction from what truly matters.
With extensive product backlog:
Product managers become backlog managers
Software engineers descend to coders
Product designers derail to pixel-perfect designers
Agile coaches become Agile rules
None of the above smells good. It actually stinks, and it stinks pretty bad.
Shall we defeat the backlog management traps?
Let’s take this premium guide to clarify how you can effectively manage your backlog.
Free subscribers: You will benefit from an overview of backlog management (5 minutes of reading time)
Premium subscribers: You will have full access to this guide (16 minutes of reading time)
It is time to kick it off with a Product Backlog Heal Check
The Product Backlog Health Check
Understanding the status quo is fundamental to transforming it. Please take a few minutes to reflect on the following questions:
Do your backlog items live forever, or do you dare to delete outdated ones?
Are your backlog items unrelated to each other, or are most of them related to an overarching goal?
Does the size of your backlog scare you, or does it encourage you to discover the future and gradually bring new items?
When you look at your backlog, do you get confused, or can you quickly glimpse where you are going?
Are your backlog items related to fulfilling requirements or context to solving problems?
Take your time. Don’t rush. The more your answers are to the left, the more trapped you are in outdated backlog management. No worries! You’re not alone. I’ve been; it’s not funny.
Use the following Health Check to understand how sustainable your product backlog is. Do that with your team, share the results with your leadership, and pick one item at a time to change it.
Now, let me help you understand how to address each item of this health check and why it matters. I assume you may be skeptical and have some questions challenging me. Here are some examples:
Why should I add a due date when I can put the irrelevant items at the bottom? You can do that, but you will get trapped in the past. Only when the old goes away does the new find its space. Trust me, whatever matters will come back to you.
I have too many stakeholders, which makes it impossible to have an overarching goal. That’s a potential situation, and falling prey to that will ensure teams have to divide and conquer, leaving little chance to benefit from solid collaboration. The more context you switch, the less productive you become.
Everyone has access to the backlog. How can I keep it organized? It’s fine to make the backlog available to your organization. Yet, it’s your responsibility to manage in a way that fosters collaboration. I will help you with that.
Software engineers want requirements, not problems. If you want to limit them to coders, then give them requirements. Yet, you won’t get the best out of them. If you want to benefit from creativity and outstanding solutions truly. Lead by context, not control.
Now, let me help you understand the essence of each health check item.
Due Date: Creating Space for Leaning
Which sentence would best describe backlog items?
The older it gets, the better it becomes
The older it gets, the less relevant it becomes
What’s your take?
I believe we can agree that backlog items become obsolete as the context changes. Once the product grows, some things don’t make sense anymore. Some bugs are not reproducible, and customers care about other things, which you have hopefully discovered.
Writing several backlog items that will never become features in your product is normal. Being Agile means learning what matters, focusing on it, and moving on.
It’s not fine to keep outdated items in your backlog just to please stakeholders so they “know” you will eventually deliver them. The more obsolete items you have, the more nonsense conversations you have.
Keep the Product Backlog clean. Backlog items age like milk, not like wine
Treating your backlog items like wine creates confusion. You end up talking about irrelevant things, distracting you from what truly matters. Yet, when your backlog items age like milk, you will find space to address learnings and progress in a more promising direction.
Don’t let the past block your learning. Instead of increasing the size of your backlog, increase the size of your trash bin.
The practice I recommend is setting a due date for backlog items:
3 to 6 months due date: Depending on your scenario, backlog items will rot faster. It depends on your learning speed. Once the backlog reaches its due date, it’s good to go.
Delete rotten items: Would you keep spoiled milk in your fridge? I don’t think so because it stinks. Would you drink spoiled milk? Unless you want to get sick, you won’t. Don’t be afraid of removing backlog items that don’t make it to a Sprint before their due date. Be afraid of keeping outdated backlog items that go into Sprint and block you from addressing your discoveries.
Setting a due date is unconventional. It’s no mystery that too many teams become feature factories.