Stop Managing Bugs, Start Focusing on Quality!

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

Let’s categorize the bugs you have and deal with them accordingly.

  1. You have a few critical bugs that crash the system or don’t have a workaround. Prioritize and fix those!
  2. 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.
  3. 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.

Going Forward

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 🙂

Get in touch via my homepage if you have questions or comments!

13 responses on “Stop Managing Bugs, Start Focusing on Quality!

  1. Thank you, Yassal!
    I’ve tried to explain this so many times before, but you’re better at putting this into words. Now I can just refer to this blog post. 🙂

  2. Great post. A change in mindset and better team collaboration will minimize documented bugs overall. Though, a great portion of bravery to start. What I like is the quality driven development approach i.e. the teams feel it is important to consider bugs right away and find new ways of working that will improve quality and prevent bugs from happening.

  3. Awesome, I am , but why mgmt dont tr yto understand these points. Having a mountain of bugs putting team under pressure which directly impact their quality and effectiveness.

  4. An interesting article.What I like about it is its simple workflow but there are some aspects I don’t fully understand.

    1.
    “If the bug needs to be fixed, prioritize and fix it now”. What does _now_ mean in this context? If your team is working in sprints, does _now_ mean to take any new bug into the _current_ sprint? Or does it just mean that the bugs will get prioritized before any other item in the backlog and may also be get fixed in a later sprint?

    2.
    Should bugs be estimated like a user story if your team works in a Scrum mode? If bugs shall be worked on before any other item and they are part of the sprint then I assume the answer would be “yes”?

    3.
    Should you really _delete_ any bug which is not considered a bug? Or would you rather close it with something like “Won’t Fix”? How do you keep your team from reporting the same issues “over and over again”?

    Thank you for that insight,
    Robert

    1. Hi Robert, thanks for the questions! I feel that the problem with most teams is that they’re already too pragmatic when it comes to bugs. As I mention the point isn’t to manage them, but to actually make sure you have a high quality product. So, in that case:

      1. “Now” = the current sprint (especially if your sprint ends in an actual release). You just got a bug logged, if you don’t fix it now, you’re saying that you’re willing to live with it, and if you’re willing to live with it you should delete it. If you get so many bugs logged in a sprint that you can’t manage to fix them in the same sprint, then the correct thing to do is to analyze why you’re getting this many bugs, and try to fix the root cause of the problem. You should not be creating so much “bad” code each sprint that you end up with a debt at the end of it, eventually you’re going to have a mountain of bugs again. The teams that implement the “we should treat it as backlog item and it should be prioritized against all other items” are the ones that end up on a slippery slope back to a mountain of bugs.
      2. A bug is something that your user thinks doesn’t work in your system. You should do what you need to do, to determine whether to fix it or not. E.g. how many users does it affect? Will it cost us too much to fix it but without any added gain? Would we release without fixing it (if the answer is yes then delete it)? Hopefully you’re not waiting until the next planning to take it in to your sprint, see point #1.
      3. Do team members really trawl through all the bugs that were closed as “won’t fix” before logging a new bug? In my experience the team just logs the darn bug anyway, then somebody in one of those long bug meetings has to remember that it could be a duplicate of something else, and then searches in the bug database, has trouble finding it, spends the next part of the meeting trying to locate it (misses out on important discussions that the rest of the team keeps having), finally finds it marked as won’t fix, but the team still needs to decide whether to just not fix this again.. If the team themselves are logging a bug against their own product, shouldn’t they just have fixed it? If a client/user logs it, then it’s great to keep taking that discussion, maybe the decision to close as “won’t fix”/(i.e. delete it) wasn’t correct. If the bug returns enough times, the team should seriously consider taking some kind of action, if those times are so far and few between that the team doesn’t remember that they decided to delete it, then so be it. Most teams who reach a healthy 0 bug balance will tend to fix more bugs as they come up, not fewer.

      I would like to add that I am a really strong proponent of making sure testing and product ownership are part of the team. If there’s a bug found the important thing is to decide what to do with it and follow through, not to log it, and keep track of how many bugs were logged and who and why and what priority or to penalize a QA engineer for logging too many bugs that get marked as duplicates or won’t fix. My preference if a team is collocated is for a team to informally discuss the bugs as they come up. If someone in the team finds it then a post-it note can be enough. If the team is distributed a post-it won’t cut it, but a dedicated slack channel could!

      Of course life isn’t so cut and dry, but these are the principles I like to start with before making any exceptions, an exception should be an “exceptional” occurrence, not the norm, so it’s best not to build it into your system, but take it on a case by case basis.

  5. I love it.

    A third option is to change the error into a slightly better error. E.g. if you get an error like “can’t call method ‘pay’ on null”, add some code that raises “Missing credit card during payment of invoice 123!” when the invoice is null.

    Then the next time the error happens, the person dealing with it won’t have to look through the backtrace to figure out what that null is about, leaving them with a bit more time to improve it further or fix it completely.

    1. Thanks for stopping by! I agree and I would fold that under “fixing it”! Same as writing a test to detect the failure in the future or refactoring the code to make it harder to have the problem.

  6. I totally agree with waht you have written. But I also have some questions.

    1. When fixing one bug or new feature, a new bug gets introduced which is not so important to be fixed. Should we consider fixing this new bug just because it was introduced while fixing another improtant bug?

    2. We find a new bug which is importat to be fixed . But the bug was found close the the code freeze and have no time to include it to the current release. Also it’s not a realse blocker. So we can only fix it for the next release. Should we just keep it and fix it in the next release?

    2. You have mentioned there are no critcal, major or minor bugs but only two types (prioritzed ones and not prioritized ones). Does this apply for customer reported issues as well? We have many issues reported by cusotmer that have been in our deffect tracking system for many years. How should we handle these bugs?

    1. Hi, Thanks for the great questions! Here are my personal opinions on how to deal with these three situations:
      1. How good of a discussion do you guys have around what is “important” and not when it comes to bug fixing? If you’re all in agreement that this is something that you can live with if you never fix it, then you should treat it as an unprioritized bug and just close/delete it. I would definitely consider the impact on the users and the code base when deciding if a bug is important or not.
      2. I would keep the bug for the next release, however I would make sure that it is prioritized and that it definitely gets fixed. If there’s no real commitment to fix it in the next release I would delete it. (If you use a branching strategy when you code freeze I would for example make it a high priority to fix the bug as soon as there is a branch available for the next release)
      3. This definitely applies to customer reported issues. My thinking is that this way the customer knows if this issue is going to get fixed or not, better than to let them live in uncertainty hoping that something might happen. This also give the customer a chance to explain why this bug is important, which might lead you to discover important improvements that could be made to the system. Nobody benefits from keeping bugs alive for years in a defect tracking system.

      I hope this helps!

  7. This is such a great article, thanks for the write up!

    I have one question. What do you think about a strategy to assign low priority and easy to fix bugs when onboarding new devs? What I mean is keeping a backlog of such bugs so that when a new comer arrives to the company, we can just look at this pile and assign those tasks to the dev. Or do you have a better strategy for having a list of easy tasks that can be assigned to new devs? Or in general, completely different strategy for tasks for a new dev?

    Thanks a lot!

    1. Hi, glad you liked the article. You can for sure keep a list of bugs/tasks that are “good for a new starter”. As long as it doesn’t feel like busy work and actually teaches the person about the system and the development process in the team. Personally I really like working in teams that use pair/mob programming on an actual deliverable with the new dev. If you program together you’re likely to learn and pick up on what’s important at this company and team. You get to know at least one person well, and you have an easy way to ask questions without feeling that you’re imposing. I think this is equally important when the new dev is more senior, this way they get a crash course into the team’s way, and at the same time can help the team see new solutions. My colleague Jan Grape has a blog entry about how to onboard a new team member that you might find inspiring: https://blog.crisp.se/2017/03/15/jangrape/how-to-onboard-a-new-team-member-faster

      1. Thank you very much Yassal, this exactly the answer I was looking for!

Comments are closed.