One of the least glamorous parts of Agile development for most Product Managers is the process of backlog grooming. It can be a challenge to get teams to engage when they’re in the middle of a sprint, it can be difficult to convince stakeholders to refer to the backlog instead of the Product Manager for simple questions, but most of all it reminds us of the gigantic list of things that we’re not doing — which is a source of frustration for any Product Manager. However, maintaining a clean, healthy, and vibrant product backlog is essential to the success of not only an Agile product team, but to the organization as a whole. When backlogs are clear, prioritized, and public, people can freely and regularly review it, raising questions and concerns as they come up rather than waiting for a big bomb drop of feedback during some strategic planning session. If you’re a fan of my blog, you know that I strongly believe that it’s the little work in upkeep and transparency that transforms an organization from just “doing” Agile to “being” Agile — and the product backlog is the number one arrow in your quiver to make change happen.
Regular Grooming is Essential
If you pay attention to all the “best practices” literature out there, you’ll be presented with the idea that backlog grooming is just one more ceremony that an Agile development team makes time for during their sprint. Every week or two weeks or month or whatever, the team gets in a room, works down the backlog, answers questions, story points, decomposes, etc. And that’s fine, but (Office Space reference warning), that’s the “bare minimum”. If that’s all that you’re doing to maintain your backlog, you’re doing a necessary part of the job, but it’s also insufficient. You see, a really great Product Manager tinkers with their product backlog on a regular basis — moving things up or down in priority; adding, splitting, or removing stories; raising questionable stories with the team on the fly. They don’t wait for some silly ceremony to monitor and maintain the backlog because, while the ceremony is useful it’s the active work on the backlog that maintains focus on the part of the Product Manager. It’s the constant tinkering that generates new and interesting ideas. It’s the daily peek and poke that allows us to see patterns that were otherwise missed. If you’re only looking at your backlog once a week, you’re not looking at it nearly often enough.
Transparency is Everything
It’s never a good sign when you ask someone where their product backlog is, and you hear something to the effect of, “Oh, you’ll need to get IT to provision you an account so that you can see that.” There are many keys to an effective Agile culture — and one of the biggest ones is transparency. The more transparent your organization is, from the top to the bottom, the more likely you’re going to be empowered to make decisions based on the information that’s freely provided. The less transparent your organization is, the less likely any one person anywhere in the company is going to have enough information to make good decisions. And at the core of any transparent product organization is the backlog (or backlogs, depending on how you’re structured). There is no good reason to hide your product backlog from anyone in the company — from support to sales to business ops to your IT staff, anyone who wants to see your backlog should be able to do so. We simply never know where good ideas will come from; we never know who will see a connection or a dependency that we’ve all missed; but most importantly when we hide our product backlog we’re setting ourselves up as unnecessary gatekeepers that everyone has to go through. I guarantee that if your backlog is transparent and open you’ll find your day-to-day job less impacted by silly questions and more impacted by serious and meaningful ones.
Don’t Let the Tail Wag the Dog
Another common mistake that Product Managers make is letting the product backlog grow too big. Sure, there are bugs that get found and ideas waiting to be implemented and…and…and… But the harsh, cold reality is that you’re not going to get to everything on your backlog, and you owe it to yourself, your teams, and your company to occasionally put the whole damn tail end of that backlog on the chopping block. Set a threshold, like bugs more than a year old of level three priority or lower. Or stories that haven’t been prioritized up beyond #100 in two years. Or toss a dart at a printout of the backlog. Whatever standard you settle on, you’ll come out of this exercise with a much stronger, healthier, and useful product backlog. Sure, you’ll have people complaining that their idea got cut — but it was never going to be done anyway if it’s stuck at #378 on the stack ranked list. We give people a very false sense of understanding when we keep zombie stories and bugs around. There will never be a time when we don’t have enough to do that we finally pull in story #254 — so why should we pretend that there is? We should obviously give people feedback and warning, and the opportunity to speak on behalf of their pet concerns — but if they can’t bring it up into the top 100 then there’s literally no reason to keep it on our main backlog. If you can’t delete it right out, then create another backlog that will just grow and grow and grow until it encompasses the entire universe. But whatever you do, cut off the tail to save the body — the conversations you’ll have will be much cleaner and more directly actionable.
