A few months back in my current role, we had a discussion with our technology leadership team, on what we would classify as a bug in our system. I’ve had a lot of different experiences across different teams on how we classified bugs, and the order in which they got resolved.
For example, a few years back I was on a team that would take customer reported “bugs” and we would review, and convert them to feature enhancements, which would typically not count against our “quality” metrics and would be much lower on the priority list of fixing. This typically happened, when the “Acceptance Criteria” was met but the customer still had a less than ideal experience using our system.
This lead to the discussion with my current team, where we all agreed, we shouldn’t de-prioritize user experience enhancements, and a new term was born. The Love Bug! We began categorizing poor user experiences as love bugs as this bug will prevent our customers from feeling delighted and loving our product.
This got me thinking, are there any other interesting stories or categories of bugs that you all have experienced?
Generally, in the teams I’ve been in, we had 3 categories:
bugs we’ll never fix, so delete them, or don’t even post them in the tracking system backlog;
bugs that we’ll fix if we have the time until the release;
bugs that are quite bad and should be taken a look at later, when we have the time to choose between new implementations and fixing older ones; plus priorities change, so half of these were thrown away.
We’ve been going through a couple of dozen bugs with a developer and a product manager/owner a few times per year to get aligned on the priorities. Sometimes it’s 1-2 of the 3 that have to decide how to quickly deal with new ones.
We never really argued on the topic of the definition: is it a bug, missing feature, missing functionality, desire, annoyance, or improvement of some kind?
The higher manager or stakeholder was always right; and if we could fix something fast and make someone happy that would help us in the long term building some trust & confidence, we’d do it.
With that second category, what happens if you don’t have the time? Do they sit in a backlog, or is it pretty much if they aren’t getting fixed in the release then they aren’t getting fixed?
There’s a chap I work with who has an interesting take (to me at least). He tends to have the opinion that bug isn’t a bug until it’s in production, So when working with things in the development cycle he is trying to avoid logging bug as a work item (we use TFS) unless it’s something we’re going to come back to later on.
Bugs that we’ll never fix => We closed them as “won’t fix”
Security bugs that we won’t fix => Close as “Accepted Risk”
Bugs that are found in the sprint will be fixed in the sprint.
Bugs that are found in the sprint but very very close to our code freeze then:
** If it’s a medium/high/critical bug; we’ll fix it
** If it’s a low/cosmetic; we’ll put it on the next sprint
Bugs that are found, not related to the current sprint.
** If it’s a high/critical => fix in Sprint
** If it’s anything else, it goes in the backlog and developers can pick it up the next couple of sprints if they have time left.
Bugs from Production (rarely happens but):
** If high/critical/security issue: Fix asap + Hotfix (rather an incident then a bug for us)
** Next sprint
We have a no-bug policy but that doesn’t mean there are some bugs
Our backlog is always like max 30-50 bug tickets (not on purpose, we just have dedicated devs <3)
We NEVER DELETE bugs from our tracking system to have full traceability of all the tickets and history. Especially if a new testers comes along and starts logging the same bugs
In my current context, my take is similar but slightly different.
A bug doesn’t need tracking with its down ticket, if the code hasn’t been merged yet. This means efforts to review and test code before it’s merged count as preventing potential bugs, but they don’t need their own tickets.
In my context, a bug in production is an incident. And bugs during integration testing, have to be tracked, for regulatory compliance, even if they are fixed before they are released to users.
