Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. Do you have a bug management system with thousands of bugs?
Do you have meetings to review high priority bugs?
Do you argue over how to use priority and severity?
Why?
Bug management is a waste of time.
Bugs fall into three categories:
Bugs that need to interrupt work. These are urgent bugs. You don’t need to argue about priority or severity. Both are high. These are the stop-everything-and-fix-it-right-now kind of bugs. You already know how to handle these.
Bugs that need to be scheduled. These bugs don’t require an interrupt but they certainly need to get fixed. They can go in the backlog and get prioritized against everything else. But be careful, many of these bugs just seem important in the moment and actually fall into the next category.
Bugs that can be ignored. These bugs can and should be ignored. Most of the bugs you encounter will fall into this category. Now you might ask, how can you just leave known bugs in the product?
Remember, everything is a trade-off. As bugs come in ask, is this bug more important than what you are doing right now? If the answer is no, then ask, is it more important than what you are doing next? If the answer is still no, then you are never going to fix this bug. Stop wasting times managing it.
You might worry, what if i get it wrong? Suppose a bug comes in and you think you can ignore it. Go ahead, do that. If you got it wrong and you shouldn’t have ignored it, the bug will come up again. You’ll get another opportunity to ask yourself the same questions. And this time around you will have more data. If it never comes up again, then you were right, the bug can be ignored.
You may have a hard time with this. But the reality is you are wasting a lot of time managing bugs that will never get resolved.
Stop managing trivial bugs and focus instead on building a great product.
Do you agree? Disagree? Share your bug squashing strategies in the comments.
We have a list of small time bugs that has grown into a mountain. Although we feel guilt and shame on a weekly basis due to it’s existence – we’ve actually been making the same choices you outline above. Interesting to have the permission to let those go and to question the tacit assumption that 100% bug free code is the way it must be.
Exactly! I suspect most people are doing this in practice. But aren’t letting go of the management piece of it. Why bother doing all the work to manage it when they are never going to get resolved? Perfect code is impossible. The more you realize that you will never get everything done the freer you are to focus on the things that really matter.
Interesting point of view. On the one hand, it seems totally reasonable for an organization that has a mountain of bugs. On the other hand, perhaps the best culture is one that doesn’t tolerate bugs – quality is so ingrained in the organization that bug management consists of fixing bugs as soon as they’re discovered. I’ve worked in both kinds of organizations.
I would guess that a lot of the difference between the two comes down to how bugs are defined. I’m certainly not arguing that we build bug-riddled products. At some places, things that are more like enhancements or are extreme edge cases get classified as bugs. What’s going to lead to a higher quality product – spending time on a bug that impacts a fraction of a percent of your visitors or improving some functionality that most people are going to use?
Of course, it’s never that black and white. Some bugs even if they only impact a fraction of a percent of users are going to fall into the first category of being urgent – privacy edge cases come to mind. But most bugs don’t fall into this category, particularly if you let anyone in the company file a bug.
And I also want to highlight the interruption cost of fixing bugs as they come in. I think it’s important to ask, is fixing this bug really more important than the other things we are working on. And that ultimately is a question of expected impact – which will have a bigger impact on end-users.
This is a great blog!
There are usually a lot of arguments in classification of bugs, because of the underlying processes that are in place to address “bugs” and “product enhancements”. All stakeholders are acutely aware of the impact these processes have – especially in terms of time taken to address the “issue”.
These arguments can be resolved quickly if all stakeholders honestly answered the question “will this have more impact than the current items being worked on” and have taken “cost of interruption” in to consideration – Items that you have highlighted.
Outside of the development teams, the cost of interruption is usually not well understood. This is where product managers can step in and guide the team to take a balanced decision.
Teresa, thanks for the post!
I think, as you describe in your comment, “highlighting the interruption cost” is the most valuable piece of this argument. Whether or not something is worth interrupting current work is really the ultimate question. Much like some other urgent need discovered via customer interaction, it’s the recognition that a new priority has been identified, so therefore some other priority must shift down – and the impact of that shift is what needs to be acknowledged.
Roger, I’ve been in org’s which thought that way, but when push came to shove, the sales side promised capabilities to buyers which made that impossible to achieve. I don’t think that’s reasonable without buy-in across the organization. Was your experience different?
If you are managing thousands of bugs you are clearly making a mistake, right. But I wouldn’t follow the advice to wait for the second occurrence of a bug, either. My personal expirience is this: Quite often one customer detects a problem way before all others and you are lucky that he reported it. You either start immediatly now fixing his problem and have a solution in hand when all other customers notice the same problem or wait for a thousand customers complaining all at once while you are empty handed. I did both versions myself and I would say the first option made a more enjoyable expirience.
Hi Holger,
I tend to agree. If a customer takes the time to report a bug it’s a pretty big indicator that that bug impacts the customer and will likely impact other customers. In my experience, most of these bugs fall into the first two categories and are not getting ignored.
Again, I’m not suggesting that you ignore all bugs. I’m Simply suggesting that if a bug isn’t important enough to interrupt current work or get scheduled in the near-term, you probably are never going to get to it. There’s an assumption that what you are working on now is more important than what you will be working on later, which is why we think we’ll get to it later. I’m suggesting that later will never come. And thus it’s not worth wasting time and energy to track and manage it.
Thanks for taking the time to comment!
Teresa
Yes, I like your suggestion. If it is really not worth doing it now it is probably not worth doing it ever. (For a bit of fun see http://geek-and-poke.com/2012/08/likelihood.html 🙂 ).
Haha. Love it. Great comic. Thanks for sharing.
Agree. Let me quickly make this process change. 🙂
I totally disagree. What happened about the Total Customer Experience that we’re all talking about? A bug to you might be a “must have” for a customer. A customer wants to be engaged with the product and feel they have some ownership to it. When they’re using a product and it fails for them, they want it fixed so they can continue to use the product.
Again, I am not suggesting that we not fix bugs. I am merely suggesting that if a bug is not important enough to be prioritized ahead of what you are doing now or ahead of what is coming next, you are probably not ever going to get to it. It falls into the same category of I’ll go to the gym tomorrow. We have unrealistic expectations of our future selves.
Having said that, if a bug negatively impacts a customer, it undoubtably is going to get prioritized and fixed.
I think this is a bit like suggesting someone lose weight on a low-carb, all-bacon diet. It probably works, and could help lots of people, but the prevailing opinion is so ingrained against it that it won’t be accepted, except perhaps in small circles.
I also think it is great insight – almost every place I have worked (mostly medium to large companies) have a mountain of low-priority “issues” (we don’t call them bugs anymore 🙂 that never get addressed.The thinking is that, “hey if this supposed-rare bug comes up again, we’ll know it happens more often than we think.” (I also think managers believe, “Hey when we don’t have anything better to do, we have lots of busy work” 🙂
The irony is that if a low-priority issue re-occurs rarely, say once a year, everyone forgets it happened before and creates another low-priority bug and adds it to the mountain.
The bug backlog becomes a landfill – there’s probably some good stuff in there somewhere, but I wouldn’t want to go digging around in there to find it. 🙂
Really good post, and I am seeing this being practiced more and more often.
At my last job, I walked into a backlog of almost 5000 open bugs. And senior management wanted a report to show that the bugs were significantly reduced. 99.999 percent of them (all but about 20) were trivial, and we knew we would never fix them. I thought hard for about 2 minutes, and closed them all “won’t fix”.
Of course, I had to do battle with our QA manager, who was paranoid that it would come back to haunt us, and it never did. Over the next 2.5 years, we reopened a handful of the bugs. The QA manager changed his tune when his personal metrics improved.
Glad you shared this
Geoffrey, thanks for commenting!
I can relate a lot to your experience. And you raise another great point that came up in a conversation today – a lot of bugs get filed because we hire people to find bugs. QA needs to be more about ensuring a quality user experience and less about finding bugs for the sake of finding bugs. But that’s a whole separate blog post. 🙂
Nice post Teresa – good to get the idea out there & I agree with what you are saying.
I find not using the word “bug” (or any derivative there of) helps. Bugs are just other pieces of work which need doing & (as you mention) need prioritising as such.
If the development cycle is fast enough (!) trivial bugs can be fixed right away. Trickier problems probably do need to be recorded & “managed”
So I’m not saying don’t manage bugs, I’m saying treat them as work that needs doing, identify their value to the stakeholders (including customers) & prioritise them accordingly.
With bugs included in the same workflow as the features being developed, it becomes a lot easier to see whats going on.
(There’s also a cultural shift away from the negativity associated with the word “Bug”)
Have you seen this post? it compliments your idea:
http://watirmelon.com/2013/02/20/bug-tracking-cane-toads/
As someone far wiser than me said – & I’m paraphrasing here – the main reason we right stuff down is because the time between the conversation & the development is too long.
If the conversation & the development happen near enough at the same time, the need to write stuff down is reduced as the developed feature is there in front of you.
Think about this statement with regards to bugs.
Thanks again Teresa,
Duncan
Duncan, great comment! I love the idea of not calling bugs bugs and removing the negative connotation with them. Also, thanks for the link, I hadn’t seen that post before and I agree it is very complimentary.