Having followed a lot of conversations and read various articles, the term “bug tracker” appears in many forms, but it got me thinking, are they really necessary in an agile environment; in fact, are they necessary at all in any environment?
“What? No where to put my bugs!!” I hear you scream. No. There will still be somewhere to put your bugs, just not in an endless pit of problems where developers are too shy to enter.
Hands up how many people out there can say their bug tracker (whatever software you use) is devoid of old bugs which are now probably classed as “tech debt”? Old bugs being more than 1 month old and then some.
There are a lot of conversations about the psychology of how we all think and react to negativity, and let’s face it, bugs, even cosmetic ones, are a negative in the sense they need to be fixed by someone.
Solution to no bug tracking software
In agile especially, bugs should be added to the ticket in play and then that ticket should not be removed from WIP, but be tagged that it has bugs and await for someone to pick it up. If someone is already assigned to fix bugs as they appear, then even better, but not always the case and sometimes, it is better for the testing to be completed beforehand.
So, what happens to those bugs that you have found that are outside the scope of the ticket you are on?
Well, this is where it gets interesting. You should at least have a backlog of work. The first place, I’d suggest is for them to go here. The reasoning for this is they are in plain view and can be discussed as a part of a sprint planning session, thus reducing the chance of them getting forgotten.
Another place is it’s own column, however, I’d err on the side of no on this one as this column can end up like any bug tracking software in that it gets ignored and as such, just grows and grows in length.
Okay, so here ends the “rant/poking the hornets nest”.
Over to all you lovely peeps!