ARE ALL BUGS CRITICAL?

Often when you listen to people that report bugs, it sounds as if the world is coming down if it isn’t fixed immediately. But are all bugs really that serious? Is it possible that some of them actually doesn’t have to be fixed right now? That we even could put them into the backlog?

There are two kinds of bugs. The ones that has to be fixed right away or the world will burn. And the ones that are annoying, but you can live with them. The first category has to be fixed immediately, obviously. But the other one can safely be added to the backlog and handled like any other user story. Being active instead of reactive.

First a word of caution. I will be a bit black and white when I write this text. I know there are shades of grey, not every bug can fall clearly into any of those two buckets, but this is easier. So, please bear with me.

There is a tendency to handle every bug the same, just because you put the label bug on it. It’s a simple classification and it’s easy to implement this into your work routine without having to think too much. The problem is, it usually means you drop everything and fix it, because it’s a bug.

But let’s face it. How many of the bugs you’ve encountered are so critical that the company will stand to lose clients, or a lot of money if it isn’t fixed? I wager, not many.

Most bugs are just annoying. They don’t hinder your work; they just bug you (get it?) Others prevent you from doing what you want, but there is a reasonable workaround. So, why do you then always have to interrupt the sprint and whack the planning out the window, just because people ask you to fix things like the text isn’t underlined in the heading?

How to handle non-critical bugs

Now, this means that we have to come up with a new way of handling these bugs. And I suggest to you that you treat them like any other user story. Put them in the backlog. Prioritize them. Refine them the best you can.

I know, I know, a bug is a big unknown, and to get enough information to refine it like a proper user story, you almost have to solve it. But have a look at it and see if there’s anything you can do at this stage, any information that you can provide and so on. That’s what refinement is for, having time for gathering missing information.

One big thing to verify is that it contains a description on how to reproduce it. If you can’t do that, you will probably never know if you have fixed it.

Just remember, this will be a problem for you, because people in general never bother to provide you with the information you need. They just say: “It doesn’t work. Fix it!” And to your question, “What doesn’t work?” they simply answer back: “As I said, it doesn’t work. Fix it!” Simplified… Or when you get to ask them, they have forgotten, because it’s been a while since they reported it. It’s no longer their problem in their reality, because they’ve handed it over to you and it is now your problem.

No story points on bugs

The only difference from normal user stories is that you can’t put story points on them. You really can’t know how big a bug is without finding out what the problem is, i.e., solving the bug.

Read about story points here.

This is the one big thing that separates them form the rest. This means your team velocity, you know, your average story point burn rate for the team, is no good for them. You have to make allowance for them when you add them to the sprint.

Or, if you have a lot of bugs in the backlog, just plan to fix one or two each sprint, and they become an integral part of the velocity. Since you always have two bugs in a sprint, the time they steal from the velocity is constant and you always have the same time left to the rest of the stories. Your velocity will include the bugs implicitly.

And the critical bugs?

Hopefully you are in an environment that doesn’t have many critical bugs. They are an exception. You just have to handle it when they come. Fix them and negotiate with the stakeholders which user story to pull out of the sprint.

But if you have a lot of them, then they too will become a part of your velocity. They become a constant time window when you can’t work on your stories, just like all the meeting time, toilet- and coffee breaks, and all the other non-planable stuff you do during a sprint.

But hopefully, you and your team is better developers than that.

— Cheers

Photo by Polina Zimmerman from Pexels