Do you have a long list of bugs? You definitely want to have a zero bug policy, but now you have all sorts of minors, majors, and criticals. You’re not really sure how to get to zero bugs (were you ever there to begin with?). You have spikes where you fix the bugs and your graphs show a steep downward drop, only for them to turn upwards again and reach new heights. Just maintaining the list of bugs is a full time job! To add insult to injury, when a team member finally gets around to looking at a bug, they usually find that it’s outdated, not reproducible or part of some long forgotten removed functionality.
There has to be a better way! How can you shift the focus from managing bugs to ensuring quality? Here’s a system that’s easy to start using, and rewarding when you follow it.
A New Attitude!
Start with a change in attitude: instead of managing bugs, focus on quality. Bugs mean the users are faced with functionality that is not working as expected. So from now on all bugs that the team agrees to fix get highest priority and get fixed now! In this system there are no minors, majors or criticals. If a bug should get fixed, it gets fixed. So what do you do with the other bugs? Remember, we’re not managing bugs anymore, if you’re not going to fix it, delete it! I know this feels a bit radical. But teams shouldn’t be bogged down by mountains of obsolete bugs. So, either agree to fix it -> prioritize it -> and actually fix it, or delete it!
I’m sure you’re wondering what to do about the bugs you already have?
Tackling the Mountain
- You have a few critical bugs that crash the system or don’t have a workaround. Prioritize and fix those!
- The majority of the rest of the bugs that are already live. They have been in your bug tracking system/on your wall for a while. Delete those. If the bug is still a valid bug it will get reported again. Don’t waste time going through lists of potentially obsolete bugs. If you’re using a bug tracking system just find all bugs created before you released and delete those.
- Finally the rest of the bugs, i.e. not critical, but where the functionality hasn’t yet been deployed, apply the new standard to dealing with bugs. Decide to either fix them right now or delete them. This subset of bugs should be pretty small if you’re releasing often. If you’re not going to get around to fixing them before the next release. Delete them!
What you want to do is to get to the point where your product works as well as it can, while providing an awesome user experience. If you have too many bugs the important relevant information will get lost in the noise.
Bugs have a tendency to become obsolete pretty quickly in applications that are updated frequently. The steps to reproduce become irrelevant, the functionality changes, the impact of the bug often gets lower. Please, don’t waste your time trying to update these bugs. You may lose a few valid ones, but trust me, someone will report it again if it’s still happening.
Once you’ve tackled the mountain of bugs you’ll be down to the bugs that you would have fixed anyway to be able to release your product. Prioritize those and fix them right away! You’re now changing the outlook from managing bugs to ensuring high quality!
Focus on Quality
Ok! Now that you’ve jumped into the deep end, and dealt with the mountain, you’re ready to move forward!
From now on, when a new bug comes in, have a short discussion to decide the fate of the bug. There are now only two categories of bugs. Prioritized ones that need to be fixed now, or ones that are not prioritized and should be deleted. Here’s what the discussion should look like:
- We can live with this bug in our system and so can our users. Maybe some people don’t even think it’s a bug.
- Delete it!
- We don’t want to live with this bug, but we’re weak and we don’t want to fix it right now…
- Ok, so we’re saying that we can live with this bug: Delete it!
- Ummmm, no, we really do want to fix it: Prioritize it and fix it now!
- We can’t live with this bug, it needs to be fixed now!
- Prioritize it and fix it now!
That’s it! You’re either fixing bugs right away, or deleting them! What often happens is that teams actually fix more bugs than ever before. Most people have a strong sense of professional pride! Now that they don’t have to sift through a massive pile of issues, the few bugs that crop up will feel more manageable to deal with so more of them will get fixed.
Finally, to ensure that this system works, the bugs that the team decides to fix must be prioritized over other work and must get fixed. In the beginning there will be more bugs to work through, as some of the bugs that were deleted get reported again, but as the team shifts its focus to improved quality there will be fewer of them. This is truly a binary system with no wiggle room. Bugs are either fixed now or deleted, there is no severity and no haggling about the classification of the bug! Are you ready to shift your focus from managing bugs to ensuring quality?
P.S. I use the word bug intentionally in this entry. I’m really not interested in the categorization of these issues, I’m only interested in providing the end user with the best experience possible! So feel free to replace the word “bug” with any combination of “bug”, “defect”, “fault”, “error”, “failure”, “issue”. Basically, if a user feels like the product is not working as it should, it’s a bug.
I’m also not interested in the nitpicky “enhancement” or “new feature” debate. If the user feels like a feature is not working and they log that as a “bug”, but “technically” it’s an “enhancement”, deal with it as a bug anyway. Either prioritize and implement it right away or delete it! I’ll leave the discussion for how to deal with a product backlog for another day 🙂