Maintaining a backlog is a delicate balance. You want to plan and keep track of your ideas, but keeping everything and trying to manage it in a perfect queue can be rough. If your backlog is too long, it’s unrealistic and unhealthy. Unrealistic because no team has unlimited resources. Unhealthy because an endless todo list can overwhelm your motivation.
So how can you get your backlog under control?
Separate work from wishes.
Every team has a list of things that they’d like to do. New features. Refactoring. Fixing bugs. Improving performance. Improving usability or accessibility. There’s always something. It’s only natural to not want to lose track of those tasks and ideas, but tacking them onto the end of an unrealistic list won’t help.
There’s always something. It’s only natural to not want to lose track of those tasks and ideas, but tacking them onto the end of an unrealistic list won’t help.
We’ve found that organizing work into three categories helps us stay grounded, hold onto our ideas without feeling smothered, and choose which work to do.
- Vision (Roadmap) The roadmap is a high-level vision for the next 6-12 months. It focuses on goals rather than features or tasks. ex. Improve Registration Process Conversion by 10%
- Wish List (Backlog) Backlogs hold your “someday” work and are separate from work that’s underway. It’s your grab bag of ideas when you’re ready to choose your next project. These are projects that might contribute to your goals, but that you are not attached to implementing. It’s more of an idea stash than a backlog.
- Action (Projects and Milestones) Milestones are for work that’s underway right now. Of the three categories, this is the only one that should be readily visible on a day-to-day basis. These should be detailed, focused, and short-term (Your next three months.)
Hide your wish list.
Anything that’s not currently underway belongs on your wish list and out of sight. You can add notes about it, but these items should be treated as evil distractions until you choose that next project. This will lighten your load and make it easier to focus and execute on your current work. If somebody adds a wish list item to your active work, ruthlessly move it to your backlog for discussion elsewhere.
Anything that’s not currently underway belongs on your wish list and out of sight.
Don’t plan too far in advance.
Things change. If you make concrete plans more than a few months out, key factors will change before you get there. If you’ve set your next year in stone, you can’t adjust course. The best time to choose that next project is just-in-time. This can often be challenging to reconcile with budgeting, but you should still delay the decision as long as possible. Don’t worry about that next project until you have to.
Keep it manageable.
If you feel overwhelmed, listen to that. Scale back your ambitions, and start with something you’re comfortable handling. A larger backlog doesn’t provide any inherent benefits. It just looms over you like a storm cloud of underachievement.
Treat bugs and features as equals.
When you have a software project, improvements are improvements. If you separate bugs from features, you create an implicit prioritization. People don’t enjoy working on bugs, and separating them creates a backlog designed to be ignored. With some teams, bugs may linger and create a looming sense of dread. If these are separate from the mainline development, it only exacerbates the problem.
A larger backlog doesn’t provide any inherent benefits. It just looms over you like a storm cloud of underachievement.
Prioritization should be based on what’s most important to customers—and thus the business. If there’s a huge backlog of bugs affecting customers, then those bugs matter as much, if not more than, any new features. Bugs and new features should compete against each other for time and attention. That competition can’t happen if bugs are second-class and dumped in a separate queue.
Focus on accomplishments.
I’ve never met a team that was satisfied with their rate of progress. Nobody ever feels like they’ve done enough. We all tend to focus on the work that’s in front of us instead of the work that’s been completed. If your backlog is front and center, it will haunt you. If, however, you look back on your last three or six months, you’re less likely to believe you’ve underachieved.
Teams need to believe that they are actively making progress, and few things undermine a feeling of accomplishment like working in the shadow of backlog mountain.
Morale can make or break a project. Teams need to believe that they are actively making progress, and few things undermine a feeling of accomplishment like working in the shadow of backlog mountain.
Declare backlog bankruptcy.
If all else fails and you believe your backlog is is a lost cause, you can declare backlog bankruptcy. If that sounds too extreme, have one final bug smashing week where you work through the key things in your backlog that can’t be deleted, and then start fresh. (Note: You don’t have to actually delete these things. Back them up. Archive them. Just make sure that aren’t looming over the team.) If the bugs are are serious, there will be new reports.
Managing a backlog and prioritizing work is a tough problem, and software alone can’t solve it. But making some changes to how you queue up the work can have a surprising impact on team morale.