Burn Your Backlog

Somewhere out there are teams with a meticulously groomed backlog. They spend time each week going through their backlog with the team’s product manager, stories prioritized, tech debt is taken care of, and old or unnecessary stories pruned. Sprint planning is a breeze, and everyone goes out for cupcakes afterward. If this is your team, feel free to stop reading now.

Unfortunately, I’ve never experienced this kind of backlog grooming nirvana. I’ve been on many high functioning teams, some of them with agile processes that worked quite well. Every one of them suffered from an ever-expanding backlog, always creating new work faster than they could complete it.

Why should you care about a messy backlog? Well-groomed backlogs tend to be small, and small backlogs are a real advantage. It’s much easier to manage a small backlog. You can sort the items by their priority, determine where new issues fit and plan for the next sprint in a few minutes. If your backlog is small enough to fit in your head, then you can reason about it as a whole and make decisions quickly. Each new story in your backlog makes it a little harder to manage, so it’s critical that each issue be worth the cost.

If it’s so important to keep your backlog focused, why does it always become an unmanageable mess? Generally, this comes from planning too far ahead. You add a new story or plan a new feature in the anticipation that you’ll need it in a few months. Once created, you quickly forget about it. You might occasionally run across the story and think, “Oh yea, we should get around to that at some point.”. Congratulations, you’ve just created a zombie story, doomed to roam your backlog in search of a brain to distract. If you find yourself doing this, it’s time to take out the proverbial shotgun and put it out of its misery.

So often, we find it hard to dispose of issues that are no longer relevant. We hang on to issues, worrying that we might lose something valuable if we closed them. We create new work faster than we can complete it. After a year or so of doing this, we end up with a backlog worthy of a Hoarders episode.

When I’m worried about something, I like to think through the worst-case scenario. These “worst-cases” usually aren’t as bad as we feared. So let’s try a thought experiment. What if you lost your entire backlog. All of your stories, sprints, and epics deleted with no backups. What would you do?

You’d probably start by re-creating the current sprint. Then you’d work from your roadmap or memory to re-create any near-term projects. You might also re-create any memorable feature requests or cleanup items.

What about all the issues you forgot to re-create? What if you forgot something important? While it’s reasonable to worry, important tasks have a way of making themselves known. If it’s important, it will come back up in a meeting, a user will mention it, or you’ll remember when you run across some troublesome bit of code. If you don’t remember to re-create an issue, and it never comes up again, have you lost anything by forgetting it?

I’m certainly not suggesting you go out and delete your entire backlog. Think of it more as a short-cut for determining whether the issue matters. Consider what would happen if it was gone. If you think you’d end up re-creating, then keep it. Otherwise, close it, and leave room in your head for the issues that have a real impact.