I thought that I would spend some time today discussing a task that I had to embark upon a little while ago with my group of engineers. Cleaning up the infamous Bug Backlog.
We had just recently shipped a new product. Bug reports were coming at us from every direction. We even had an outlet where users could submit bugs directly into our system (I highly recommend a CS middle step). After a short while we were finding that we had no clue what was bugged and what wasn’t. We created several duplicates of the same issue because we had trouble finding the exact ticket that we wanted.The team got stressed since all they saw were bigs, bugs, bugs…
If that sounds at all familiar… then I guess you know what it is like to work in a fast paced environment on a live product. Don’t ever be willing to accept excuses such as “Oh, that’s just the way it is here” or “Person XYZ is in charge of that so it is not my concern”. As an engineer on a product, as a engineering manager, as a product manager, as a producer, as a quality assurance agent, as a customer service agent… everyone has a vested interest in keeping a lean and under control bug backlog. Here are a few easy steps to get your backlog under control.
1. Ensure everyone is using the same tool
This might sound straight forward – but be careful not to spin up extra tools to do what your bug tracker is doing. These are often called “Tracking Sheets”, “Task Lists”, or “EOW Reports”. Too often I see people using Google Docs or other programs to track what is already beign tracked in their bug tracking software. Now let me be clear. I have no problem with a routine that exports data from your bug tracking software into another tool for reports and displays… just be cautious not to begin changing and tracking data in multiple places. This causes data to get out of sync, causes people to be confused as to what they are looking at and so forth.
2. Know your software — In and Out
It always amazes me when a company spends thousands of dollars on a piece of software, but then refuses to pay a dime on training their employees on how to use it. That’s like giving a machine gun to a 6 year old and saying good luck. Take the time to learn the ins and outs of the software you are using. Take a class, read the tutorials, do whatever is available to you to understand and know how to use the software. Let’s assume you spend 1 day learning how to use your software. the amount of time this investment will save over the next year will equal way more then the 1 day spent to learn about it. Take the time and learn your software.
3. Build Filters, Reports, Queries, etc
Chances are that the report or filter you need, someone else needs as well. It’s also likely that the developers of the software know this and provided the report or filter in some sort of build in fashion. Look for and use these global built in reports. Even if it is not 100% exactly what you need, the built in tools keep things consistent and save a ton of time. if custom filters or reports are needed, take the time to build them. It will make your regular reporting and checkups much faster. It also helps to build consistency week or week.
4. Use filters and reports to find old issues
Use the built in reports and queries to find issues that are older then a certain date. I often use the rule of thumb that if an issue has not bee looked at or touched within the last 3 months, chances are that we are never going to address the item. Close these tasks aggressively. Many of them might seem like good ideas — but the fact is that they are not important enough to be at the top of your list and probably never will be. There is nothing wrong with closing a ticket with “Cannot Fix”, “No Time Allotted”, etc…
5. Use Agile Stories
For those who don’t know, Agile Story writing a method to unify how tickets are written. It is the “As a”, “I Must”, “So That” method for writing a ticket. The benefit to using this method is that all members of the team end up writing tickets in the same manner. Not only does it help to simply to ticket writing and tasking portion — but it also helps to identify duplicates. Since the tasks are all written in a similar manner the title is no longer misleading from the task within.
6. Find issues relating to old features
It is very likely that there are a lot of tickets relating to features that no longer exist in your product. Use searches or filters to ferret out and find these issues that are most likely no longer even valid. If the feature has changed I advise teammates to open new tickets with the new issues and to close the old ones. They can still be linked to if needed. The problem with keeping old tickets alive if the feature has changed is that the conversation and history of the previous ticket persists. This can be very confusing for a new dev on the ticket to understand the full picture. A separate but linked ticket allows them to start afresh yet still provides a reference point for something that may be related.
7. Find issues that were created by people no longer on the team
These tickets are often comical. Some of them may still be good and valid… but you may find that many of the tickets are personal opinions and never really got traction with the group. these tickets can easily be closed as they do not have a “champion” to figure out and work on the ticket.
8. Scour low priority tickets aggressively
Do a very aggressive pass against your low priority tickets. Try to imagine which tickets are ging to sit in your queue for the next 6 months without being touched. These tickets might be really good ideas — but there is nothing wrong with closing them saying that we will not have time to perform the work.
Cleaning up your backlog can be a difficult task — but it allows you to work more effectively as a team and as engineers. You can more easily find the critical issues that need to occupy your time and lower the chance of items slipping through the cracks.