There is never enough time to fix all of our application's bugs. So everything we don't fix gets moved to the bug backlog, a list somewhere within our ticket tracking software. If a bug isn't critical enough to be fixed straight away, it ends up in the backlog. If a bug report is ambiguous, missing vital information, or making odd requests, it ends up in the backlog. All of the bugs that no one wants to fix, but no one wants to be the one to close either, end up in the backlog.
Bug backlogs are never easy to work with, and their nature tends towards helping accumulate bug tickets rather than helping anyone resolve their contents. Many of the tickets that end up in the bug backlog are not worth fixing. They are not ready to start or are of dubious value. They need to be furnished with more information, triaged, closed, or moved to a more appropriate location. Keeping them as-is will ensure that they don't get fixed, and will make it harder to address the real bugs in the backlog. If you're a developer scrolling through the list, you will avoid these bugs; if you're someone who has decided to take charge of the backlog, you should be dealing with these first. What follows is a list of the types of bugs that shouldn't be "sitting" in your bug backlog.
The "just in case it happens again" bug
No one is sure how to reproduce this issue, and there isn't enough information to even start looking. This type of bug ticket is kept alive in the hope that it will happen again, and the second time around, someone will uncover a bit more information. These bugs stay open for years without addition, taking up space and adding noise. However, closed bugs are still searchable, and closed bugs can be re-opened, so there is no real reason to leave them open.
Diagnosis: Remove.
The old bug
If you have never taken steps to organize, triage, or clean your bug backlog, your backlog will have bugs as old as your application itself. If a bug has gone so long without being fixed, its ticket is probably low quality and meets some of the other categories on this list. Regardless, it should be closed. If no one has reraised the bug in the last year, it can't have been that important. The bug might have been resolved under another ticket, or a refactor or redesign has rendered it irrelevant. Resources and attachments, such as log files, test files, and videos, may have gone missing. The report is no longer reliable, and the expected outcome may be incorrect as the application has changed.
Diagnosis: Remove.
The duplicate
The longer the bug list, the harder it is to check for duplicates, and the more duplicates make their way into the bug list. They add noise and split information between tickets. A ticket will often be picked up and resolved, but all of its duplicates will remain, creating confusion when later attempts to reproduce them fail.
Diagnosis: Track down all of the duplicates and combine them into a single ticket.
The half-discussed bug
The comments on this bug show that an extended discussion took place six months ago without a resolution. Perhaps the expected outcome was unsure, or there was controversy around the best way to solve it. It is unclear not only what is expected, but also whether it still belongs to any of the people discussing it. The discussion may have been so detailed and fraught as to suggest that this bug will require a lot of specialist knowledge in the affected area of the application.
Diagnosis: Assign this ticket to someone involved in the discussion to make a final decision.
The tacked-on bug
The comments on the bug ticket detail a new bug, unrelated to the original bug described in the details. Perhaps someone fixed the original bug, but subsequent testing has revealed a new error. It can be confusing to determine what problem you need to address—has the bug ticket been left open because of the new bug, or do both still need fixing? Is whoever fixed the original bug working on the second? Further, the "tacked-on" bug makes it complicated to determine the severity and priority of this issue, as it might not match the original's severity and priority.
Diagnosis: Split the ticket into individual tickets.
The bug that should be a feature
This issue meets the definition of a bug until it comes time to fix it. The solution required is more akin to developing a new feature than fixing a bug. There might be complicated requirements to decide on and enumerate, or new UI designed, or new architecture created to solve the problem. Whereas an ordinary bug might need input from developers, testers, and product owners, this bug might need input from UI/UX, technical leads, DevOps, and other specialists. Rather than addressing it as a bug, it might make more sense to put the problem through your team's more powerful and robust feature pipeline.
Diagnosis: Move to your feature backlog.
The feature request
While some bugs need to be treated more like features, some features manage to make their way into the bug list. The reporter is either misunderstanding the existing behavior or accidentally requesting new behavior. Either way, there is nothing incorrect that needs fixing. These bugs are problematic because they skip the proper channels for feature work. Features requested via the bug backlog can skip the product owner, UI/UX, and everyone else who should be involved in feature creation and prioritization.
Diagnosis: Move to your feature backlog.
The bug with missing fields
Without all of the information at hand, it can be challenging to determine whether this bug is appropriate to pick up. It might be missing replication steps, priority and severity, an expected outcome, or labels that indicate the part of the application affected. You might go ahead and start it anyway, wasting hours or days gathering the details yourself, only to find that bug has no value or never occurs in the wild. Maybe no one wants it completed, or it would take longer to complete than you have time available. You might find the bug's source is not where you first expected, and that you just aren't familiar enough with the affected region of the application to create a good fix.
Diagnosis: Either you or the original reporter need to populate the missing fields.
The high-priority bug
When your bug backlog gets large and disorganized enough, bugs that are of critical importance can end up getting lost. Perhaps the tickets don't have enough information, no one realizes just how important they are, the noise of other bugs drowned them out, or they were waiting for someone to furnish them with extra explanation or details that never came. Whatever the cause, these sorts of bugs need resolving, and given their urgency; the bug backlog is the wrong place for them.
Diagnosis: Move this bug to your high-priority bug list or assign it directly to a team.
The low-value bug
Some bugs in the backlog are truly worthless. They might never affect anyone, or their impact is too small to be noticeable. The path to replicate them might be convoluted, or there are already other measures to prevent them from causing harm. The cost of fixing these bugs will outweigh any value that you could obtain by resolving them. Perhaps these bugs were originally logged when a feature was still in development, when the feature was fresh in everyone's minds, and bugs were comparatively easy to fix. However, time has moved on, and the scales have shifted; the bugs have remained low value, but have become disproportionately time-consuming and difficult to resolve.
Diagnosis: Remove.
The blocked bug
Many bugs end up with a blocked status without any indication of why. Once blocked, a bug is unlikely to become unblocked, as we eventually lose track of what initially stopped it. Further, a bug buried in the bug backlog isn't helping to resolve the blocker. In my experience, resolving blockers requires active attention, which doesn't happen when the blocked items languish deep in a list no one is reading.
Diagnosis: This one can be tricky; you may need to create a process for surfacing blocked bugs.
The bug that everyone has picked up and put back down
Some bugs are particularly intractable. They might be challenging to reproduce or fix. They may take more time to resolve than anyone has to spare. Perhaps no one could find an owner to decide what the expected outcome should be, or a bug is also guilty of some of the other criteria in this list. Over time, half of the development team has had an attempt, before admitting defeat and returning the bug to the backlog. Determining whether a bug has gotten into this state can be difficult, as each individual's investigation and subsequent retreat will often occur before they leave any fingerprints on the bug ticket. Regardless of the cause, this bug has chewed up the time of many separate investigations, but it is unlikely to be solvable in its current state.
Diagnosis: Someone needs to decide whether this bug is still valuable. If so, you will need to make space in a team's capacity to accommodate it.
The "clean up this code" ticket
Few teams have effective methods for tracking technical debt, and when it does get written down, you tend to find it recorded in strange and inappropriate places, including as bugs within the bug backlog.
Diagnosis: Find a better method of tracking debt and move the ticket there.
The bug that is not worth the damage to fix
Thankfully a rare occurrence, this bug is seldom worth fixing. The replication steps may be convoluted or unlikely to occur, and without disproportionate restructuring, the solution will cause significant damage to your codebase. The hack or workaround required to fix this bug will place overhead on all future development and testing. You need to make a judgment call whether the impact is worth it.
Diagnosis: Put some logging in place to gauge how often it is happening in the wild before fixing it.
The bug that belongs to a different team
When you have multiple teams working on the same product, each team will end up with areas of the application that they have specific or recent experience working with. In this situation, the teams might also end up sharing the same bug backlog. However, in this configuration, each team can pick up only a fraction of the backlog suitable for their skillset. The more teams sharing a backlog, the harder it is to find appropriate work in the shared backlog, and the higher the chance of accidentally starting work on a bug that is outside of your individual experience and knowledge.
Diagnosis: This is a systemic issue; either create multiple separate bug backlogs or figure out a labeling system.
The predicting-the-future bug
Rather than describing a current problem, these bugs make some predictions about the future state of the application and extrapolate the problems that might occur. Typically they linger in the bug backlog in the hope that they will one day be relevant. "We need to make x more robust since it will cause us problems once we move to y." "If we ever make this API public, then z will cause us problems." These bugs tend to be political statements about the future direction of the application rather than actual problems that need fixing. Regardless, when and if you make any significant changes in the future, you will probably rediscover these issues anyway, so there is little value in keeping them around.
Diagnosis: Remove.
The copy-and-paste from a crash reporter
The descriptions in the tickets for these bugs are just a stack trace copy-pasted from one of your application's third-party crash reporters. By itself, a stack trace alone isn't enough to go on; most of the stack trace will just be a list of system calls. To fix the underlying bug, you need to investigate and address the exceptions and logs accumulating in your analytics tools. However, creating a bug ticket with insufficient information that sits in the backlog for six months won't achieve this.
Diagnosis: Remove.
The bug that was for a moment in time
We don't report bugs assuming that it will take a year or more to resolve them. Instead, we create bug reports with some assumptions about the current state and priorities of the project. Perhaps a ticket was created thinking that the creator or their team was also going to pick it up, but it fell by the wayside. Perhaps the bug was addressing something topical at the time it was created but is now a low priority. Once they have sat in the queue for long enough, bugs will go out of date.
Diagnosis: Verify whether the ticket is still useful and relevant.
The problems of a disordered backlog
Now that we understand the sorts of bugs that cause us trouble, it is worth elaborating on why they don't belong in your bug backlog.
Typically, we interact with the bug backlog in one of two ways: either we ignore it and pretend it doesn't exist, or we turn to it as a source of work when there is a lull in feature development and priority bugs. We're looking for something we can complete in a fixed timeframe to keep us busy until the next piece of work is ready to start. However, this approach does not line up with what is in the backlog. It is easy to spend all of the time we're trying to fill with searching through the backlog and doing light investigations just to find something we can pick up. Even when we finally settle on something, we're frequently caught out by ambiguous bugs that are much more time consuming than anticipated, disrupting our other work for weeks. Alternatively, bugs will require input from other roles, such as product owners clarifying outcomes, or testers helping us replicate the issues. But in doing this, we accidentally obligate additional work to the same people who are already flat out preparing the next round of feature work for us.
Without prioritization or order, it is easy to think that all bugs in the backlog have an equal priority. Even though there should be no high-priority bugs in it, the backlog will still contain a variety of priorities from unimportant to moderate. Regardless, the developers will often choose to go after the lowest-hanging fruit first, working on the interesting or easy bugs of low importance over those of moderate priority. Alternatively, we spend too much time searching through the backlog looking for something that we perceive has value, forgetting that assigning value and priority is not our role.
Bug backlogs can be a significant source of wasted time. It is easy to fall into the trap of starting work on a bug, putting it back because it doesn't meet some start criteria, then having another developer come along and repeat the process. Even when we keep going, we often need to choose between writing off the time already spent versus the additional time it will take to get up to speed in an area of the application that is outside our specialties and responsibilities. Bugs are not free to fix. Even when we don't have feature development or pressing deadlines to focus on, low-priority bugs compete for our time with other tasks like paying down technical debt, automation and quality of life improvements, preparing for future work, and upskilling.
The final risk of an unmaintained backlog is that, over time, developers start to lose faith in the value of fixing the bugs in the backlog. When we feel we are not creating any value and no one cares about the trivial problems we are fixing, it is that much easier to pretend the bug backlog doesn't exist.
Taking back control
To get the bug backlog to a state where it isn't standing between your team and their ability to fix bugs, you have several options. First off, someone can go on a culling spree, closing the majority of the bugs in the backlog, and resetting it to a manageable size. However, depending on the amount of rationale needed to close a bug, this can take some time, and it does little to prevent the problem from reemerging in the future. Alternatively, you can shift your team's culture and empower everyone to feel they can close bugs or recommend they be closed. Too often, we worry about making a bad call or offending whoever opened the bug. However, the best approach I have been a part of is to have someone take ownership of the bug backlog. The new owner can hold regular triages, bounce any bugs that don't meet the standard back to their creator and direct each bug towards the team best equipped to resolve it. The net result will be a couple of people spending a bit more time in meetings, but overall everyone spends a lot less time dealing with the backlog.
Even in companies with otherwise high levels of process and organization, I have seen the bug backlog treated as an afterthought. Either we delegated resolving its contents to a fictional future time, where we would have all of the time we needed, or we had expectations about tackling the backlog in real-time that simply failed to line up with reality. It's naive to think that a developer has the free time to work on unimportant bugs. For any bug within the backlog to be completed, it needs to be as easy and fast as possible to complete - whether that means improving the quality of the bug tickets, or cleaning out the noise, time-wasters, and general trash.
Top comments (0)