Every company deals with a backlog of issues. Some backlogs are small, some are embarrassingly large, all of them represent work that still needs to be done. One of the questions that nobody wants to answer though, is who owns that backlog?
Proposal: QA should own the issue backlog. To be clear, this is referring specifically to the issue backlog, not the product backlog or project roadmap.
Why: Generally the entire backlog seems to belong to the product manager, who creates the team roadmap based on company needs and objectives. Product managers, however, have a tendency to focus on product, and new features. This isn’t inherently a problem, it’s their job, but the need to focus on product needs tends to leave issue management in the dust.
What this means is that the PM might make an attempt to add bugs to every work cycle, but the need to figure out new feature work, designs, and everything else they do (I’m not a PM, can you tell?) doesn’t leave time for giving issues the consideration needed to properly prioritize them. This usually leads to more incoming issues than outgoing issues, which eventually leads to an issue backlog numbering in the 100s or even (shudder) the 1000s. At that point nobody can figure out how to organize it, and who can blame them?
So what does good bug backlog management look like?
Priority
A good issue backlog is prioritized, even if nothing else happens with the endless list of issues that might someday get solved, every existing issue should have a priority. At a minimum somebody can reach into the black hole and pull out something that at one point was considered a high priority issue to fix.
That is just step one though. While it’s important to have a well prioritized backlog, leaving it at that means that the only things that ever really get fixed are the high priority issues. Which leads to step two:
Timelines
A full discussion of issue fix timelines merits its own post, but I’ll touch on the importance of them here. Generally speaking, high bugs are the most important things to fix (excluding critical issues, which are obviously higher, but should be far less common). Most commonly, what this means is that anything not marked as high priority might as well be marked as ‘will not do.’ Standardizing timelines for issues helps to alleviate this problem, which means teams should agree that medium priority issues should be fixed within x number of months, and low priority issues will be fixed in y number of months/quarters.
The job of the quality assurance engineer is to bring to the team’s attention any issues that have gone longer than agreed on in their resolution, the team then decides on the best course of action by either:
Fixing the issue
Changing the priority
Marking the issue as won’t do
This is a great way to clear out an old backlog, because if a low priority issue has been hanging out for six months, the likelihood of it ever getting resolved is pretty much zero.
Total Issues
The reason issue backlogs spiral out of control is because at a certain point the number of open issues is so large, nobody is willing to look at it. Somebody looking at a backlog of 50 issues sees something manageable that can be tackled with some concentrated effort. 100 issues is a lot, but it can be kept under control. 500 issues is a lot, and who knows where the important issues are. 1000 issues is just noise, and for all the attention it gets can be treated as empty. If priority and timelines are being handled properly a backlog should rarely reach more than 250 outstanding issues.
So how do you get there?
If you’re reading this while staring down an issue backlog numbering in the thousands, this probably all just seems like an impossible dream. Here is how I handle it.
Step 1
Turn off anything that is automatically creating issues. If issues are being created automatically, and the existing backlog is numbering in the high 100s, all that’s really happening is pointless alerts being shouted into an unlistening void.
Step 2
Delete every unassigned issue that hasn’t been touched in the last year. That’s right, delete, not close. If it was important enough to keep around, there’s probably a duplicate that’s more recent.
Step 3
Ping people about every issue assigned to them. Most of the time the answer will be some variation on: “Oh, that’s not an issue anymore, it’s been fixed.” Then get them to close the issue (don’t do it for them). It sounds petty, and annoying, but managing an issue backlog also means working to make sure other people aren’t using it as their garbage bin. The backlog is in a bad state because of bad habits, and breaking those habits is usually painful, but they need to be broken.
Step 4
Metrics. Keep track of how many issues are coming into the backlog every week, and how many are going out. Encourage your team to start trending down, even closing one more issue a week than you have incoming is a win at this point.
Step 5
Be consistent. This is the hardest part, but it’s also the most important. Properly cleaning out an issue backlog can take months of hard work, but in the end it will help your team have a clear vision of their issues, and a plan for improving their quality.
Let me know your thoughts.
Top comments (0)