I noticed one of our development teams was creating new Jira Issues for each bug found during the development cycle. IMO, this is an antipattern.
These are the problems it can create, that I can think of:
- New Jira Issues (bug reports) are creating unneccessry admin work for the whole team.
- We see these bug reports cluttering an Agile board.
- They may have to get prioritized.
- We have to track them, they have to get assigned, change statuses, get linked, maybe even estimated.
- They take time to create.
- They may cause us to communicate via text rather than conversation.
- Bug reports mislead lazy people into tracking progress, quality, or team performance by counting bugs.
- It leads to confusion about how to manage the User Story. If the User Story is done except for the open bug reports, can we mark the User Story “Done”? Or do we need to keep the User Story open until the logged bugs get fixed…”Why is this User Story still in progress? Oh yeah, it’s because of those linked logged bugs”.
- It’s an indication our acceptance criteria is inadequete. That is to say, if the acceptance criteria in the User Story is not met, we wouldn’t have to log a bug report. We would merely NOT mark the Story “Done”.
- Bug reports may give us an excuse not to fix all bugs…”let’s fix it next Sprint”, “let’s put it on the Product Backlog and fix it some other day”…which means never.
- It’s probably a sign the team is breaking development into a coding phase and a testing phase. Instead, we really want the testing and programming to take place in one phase...development.
- It probably means the programmer is considering their code “done”, throwing it over the wall to a tester, and moving on to a different Story. This misleads us on progress. Untested is as good as nothing.
If the bug is an escape, if it occurs in production. It’s probably a good idea to log it.