Trimming Large Backlogs

This morning, a buddy was wrangling a Trello board. It was packed with tasks and it was getting hard to plan work. Not long later, I got an email:

What’s your recommendation for a Very Large Backlog?

I see a lot of Very Large Backlogs in DevOps. Everybody is moving to the cloud. Everybody is automating. Everybody is paying down technical debt. There’s a lot to do and a lot of it shows up in the backlog. My buddy doesn’t work in DevOps, but VLBs are common in my world and I have a few recommendations that’ll help in any field.

How you deal with this depends on the tasks in your backlog. There’s no magic method. But, I have seen several recurring patterns in big backlogs. I’ve also found some ways to deal with them:

  • Tons of small, lower-priority tasks. I’ll often bump these up in priority just to get them out of the backlog. One of my mantras is, “You have to do a sufficient amount of the little stuff every week to keep the business running.” If I’ve got a bunch of cards for “rotate password on [service]” and “set up new account for [person]” and “email instructions for [task] to [coworker]”, I’ll just sit down for three hours and smash through them. It’s better to spend time doing the work than to spend time tracking it.
  • Tasks that are vague or not actionable until far into the future. These are good candidates to convert to a bulleted list in a markdown file. I keep a fiddle directory with a noodling.md file where I track these. It’s a workspace for me to think about stuff and experiment. Like, “Consider switching from Google Apps to Office 365”. It’s something I want to remember to think about later but it’s not really an actionable task that needs to be scheduled.
  • Planning tasks. I try not to put these in the backlog. Things like, “write a plan for how I’m going to write the code/copy/proposal for [task].” There are a lot of sneaky variations on this pattern, so I go through my backlogs and read each task carefully to look for it. I usually just delete them. If a task fits in one sprint, I consider my approach when I start the task. Orienting myself and planning my implementation is part of the development process, not something I do separately. Any task that’s so large I can’t plan it in-line isn’t a task. It’s a project and it needs a whole other process.
  • Tasks that just never seem to get prioritized. Backlogs often bloat with tasks that’ll never be high-value enough to prioritize. Like, “define code style standards for all mah code.” Or, “figure out how to install that JIRA plugin we talked about in standup that one time.” There’s only so much magic you can do to tame a large backlog. Too much work is too much work. One of the best things you can do is sort by value and drop tasks from the bottom. Put a note in the card and close it (don’t delete it, you want it to show up in searches so nobody adds it again). If the backlog is too big to complete, your options are to hire workers or cancel work. Hiring workers is slow and expensive. Canceling low-value work is fast and cheap. (You can also look for ways to work more efficiently but those are usually gains of just a few percent and won’t overcome a large backlog.)

There is a lot more to backlog management than fixing these patterns, but these can help a lot in shrinking your backlog down to something manageable.

Happy grooming!

Adam

If this was helpful and you want to get the latest patterns for project management in your inbox, subscribe here. If you don’t want to wait for the next one, check out these: