image by beta news
At many customers I visit, I see a lot of effort being put into classification and managing bugs. Their bug-list may contain more than thousands of items, all neatly documented with screenshots, ways to reproduce and a severity and impact classification. Clearly, many hours have been invested to properly administer bugs.
Creating a list of bugs delivers a well organized inventory of technical debt. Spending time on evaluating and administering bugs with the goal of putting them on a list is wasteful. I recommend to stop doing this.
“But bugs are important! Our customers suffer from them!” I could not agree more with that. But we need to make decisions to prioritize work, including bugs. Existing bug handling processes result in some bugs being picked up and others later. Much later. Or actually: Never… When there are 4321 bugs registered, how realistic is it to think that bug number 4320 is ever going to be picked up? And if we do, how big is the chance it is still relevant by the time we try to fix it? It will take serious effort to reproduce the bug and most probably the bug is no longer reproducible, because the code in which it occurred has already been refactored (a couple of times), or the developer finds out it is a duplicate entry.
The solution is elegant and simple: Implement the “Zero bug policy”.
Start with accumulating all bug registration sources in the company into one single source of truth. You will be surprised how many different lists are maintained: Bugs stored in the service center ticketing system, the product backlog tool, spreadsheets and so on. Combine everything in one single source of truth. We’ll call that “the ultimate bug-list”. (Maybe not all bugs belong to your development group. If so, ignore all bugs that cannot/should not be fixed by you.)
Then we count the number of bugs. This number will become the “Zero-Baseline”. From the next sprint on, we consider this number of bugs to be “zero”. This means that no new bugs are allowed to be added. The baseline cannot go up.
Let’s assume we found 3223 bugs on our ultimate bug-list. Eleven new bugs are raised during the current Sprint. The idea is that those eleven new bugs will be either fixed in the next sprint, or the bugs will deleted. Yes. Deleted! It is very simple and binary. We throw them away. Why? Because this will stop our technical debt (caused by unresolved bugs) from growing. We don’t put them on a “maybe-list” or “we should not forget” list. With these lists, we were just fooling ourselves because we were not working on these bugs anyway.
If we decide not to delete a bug, we put it on top of the Product Backlog. By consequence, if there are many bugs reported during the Sprint, we may not be able to work on new functionality in the next Sprint. This is a good thing because having many bugs is an indication of poor software quality. We should stop creating new functionality to prevent the quality from deteriorating further and generating even more bugs. We dedicate as much time as needed on fixing all bugs that come in.
The rigorous Zero-baseline approach will force us to clean our code. And it will force us to make the customers a little less disappointed by reducing the "buggy-ness" of the application.
If a critical bug is raised, then all hands should be on deck. This is what is know as the “Stop the line”. This means at least one team should drop the Sprint work and resolve that issue first.
image by S. montagud
When the number of bugs coming in per sprint decreases, the PO should agree with all teams to set a fixed number of bugs that the teams must resolve every Sprint. Per Sprint there we will move X number of bugs times X number of teams from the Ultimate bug-list to the PBL. This will make the zero-baseline go down. The number of bugs per sprint can be any number, but it needs to be realistic in relation to the total number of bugs on the ultimate bug-list.
Probably, the bugs have been ordered before, so we can take them from top to bottom from the ultimate bug-list. I advise to not spend too much time on re-prioritizing them or on estimating them. In the example picture below, the teams decided to discuss the bugs with their stakeholders in a bug refinement session. Team delegates join these sessions with stakeholders to verify (reproduce) and assess bugs.
image by roland flemm
To create focus, the PO can filter the Ultimate bug-list during refinement to select bugs that are related to new functionality that will be taken into the sprint. The teams pick their agreed amount of bugs and put them on their Sprint backlogs. The rest of the Sprint backlogs can then be filled with regular Product Backlog Items.
After eating away bugs from the ultimate bug-list in every Sprint, the bugs will start to become less relevant after some time. The bugs are old, less high in priority and impact. With this, the ultimate bug-list will start to loose its value too. That’s when the remainder of the ultimate bug-list should be thrown away entirely. The zero-baseline is then at zero and the practice of deleting less important bugs should remain.
Good Luck! If you have questions, let me know.