The more items you have in the backlog, the less you can innovate.
Your product backlog should be a vehicle to drive value but it often becomes a distraction to what really matters.
Over the last 15 years, something has surprised me. The best product teams I’ve encountered acted reckless with their backlogs. They had less than 50 backlog items and deleted more than they created. While that may be controversial to most teams, it allows you to keep a better eye on what’s important.
How much time do you spend managing your backlog every week?
The more time you spend on the backlog, the less time you have to learn. To get a rough idea of your backlog management, consider the following timeframes:
Now, let’s cover the dangers that might get in the way of your backlog management.
When you look at your backlog, do you see a path to a goal or a six-year-old’s Christmas wishlist?
Let me share a brief story.
I was about to travel to Brazil, and my godson asked me, “Could you bring me a Marvel cap? Please. Ahh, I also want Captain America socks. I love the latest Top Gun movie and want to look like Tom Cruise. Please bring me his Ray Bans. And don’t forget I love games; I’d like a PlayStation 5 and a nice strawberry jam to eat while I play.”
Can you imagine that? It would look something like this:
When I reviewed my backlog that day, I realized it was a Christmas wishlist from marketing, operations, customer service, leadership, and more.
If you try to please everyone, you’ll end up pleasing no one.
Focus is fundamental.
Are you a product manager or a story writer?
I wrote user stories so perfectly for many years that any software engineer could implement them without talking to me. Some even loved that. However, they didn’t convey the problem they were solving for.
When you write perfect stories, you:
That said, you end up not talking about the real problem. It’s better to write broken stories because:
Focus on the collaboration, not on precise stories.
How many backlogs does your team have?
I worked with teams on a backlog for features, another for bugs, and then another one for tech and design debt. I observed teams continuously talking about the multiple backlogs instead of focusing on their goals.
One product = one product backlog.
Everything that paves the way to create value should be in your product backlog. If you create multiple backlogs, you’ll develop silos as a by-product.
Some product managers develop a protective attitude towards the backlog and block anyone else from creating items there. Because of this, the product manager becomes a bottleneck.
Great product managers lead by context, not control.
The more you control the backlog, the less time you’ll have to learn.
Product management goes beyond backlog management. You need to understand your opportunities, connect them to business objectives, and prioritize. You’ll struggle to do that if you’re a bottleneck.
How do you populate your backlog?
Some teams have an idea, decompose it into multiple backlog items, and then separate the items into future sprints to clarify what gets done and when. But does that look like product management or project management?
Product management should uncover what drives value and lead teams to realize that potential value. But making that happen can be messy because you don’t know what you don’t know. You cannot always predict what gets done and when. You need to continuously adapt the course according to what you learn.
What’s the oldest item in your backlog?
If you told me it was created two years ago, I’d say, “Long live the dinosaurs.” The older a backlog item is, the less relevant it becomes.
I understand many teams want to keep things in the backlog so stakeholders won’t be annoyed. However, outdated backlog items don’t help anyone.
My recommendation is simple: keep the trash bin bigger than your backlog.
If something didn’t make it into your product six months after you created it, it’s time to let it go. Delete it if you can. Otherwise, archive it, but don’t keep it in the backlog.
When you look at your backlog, do you see features to implement or problems to solve?
The first is the most common, while the second is rare. Sadly, focusing on features doesn’t mean maximizing value.
When you focus on features, your work comes when you ship the product but you cannot guarantee that you’ll deliver the desired outcome.
When you focus on solving problems, your work shifts towards reaching the desired outcome. You can try out multiple features before something works. And yet, your focus is clear. That’s why you can adapt.
Understanding the status quo is fundamental to transforming it. Take a few minutes to reflect on the following questions:
The more your answers lean to the left, the more trapped you are in outdated backlog management. No worries! You’re not alone.
Use the following health check to assess the sustainability of your product backlog. Do this with your team, share the results with your leadership, and then change one item at a time:
The product backlog is the home of your product. Keep it clean by the following this routine:
Now, let me ask you a question: What would happen if you stopped cleaning daily? What if you didn’t remove the dust for a few weeks? It wouldn’t take long to make your home so unpleasant that you wouldn’t want to live there.
Now, apply the same thought to the backlog. If you stop cleaning it, you let it be. What would happen? You would probably grow to resent it.
I find that this schedule works well for me:
Backlog management shouldn’t take more than five hours a week, so you have enough time to focus on other matters. Try to apply the extreme backlog cleaning technique to reduce distractions.
Be careful with cluttered and precise backlog items because you’ll struggle to understand what matters most. A mindful backlog should pave the way to create value instead of maximizing features nobody uses.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Daric Snyder talks about developing supportive, user-friendly healthcare software that layers on top of traditional health records systems.
Our product team transformed user research with weekly research sprints — a high-cost, high-reward alternative to continuous discovery.
Monique Piras shares how she helped redesign the feature brief and product requirements template and quarterly planning process.
Digital product leader Aditya Raju talks about the importance of meeting users in the healthcare ecosystem where they are.
Learn more →
