Many times I've observed bugs being logged against particular stories that takes Product Owners a lot of time to triage that don't end up being important enough to fix. Either it's an acceptable behavior that wouldn't have a material client impact or simply not something Product Owners see as important as something else in the backlog. How can this phenomenon be dealt with so that teams can keep moving?
This sounds like a good topic to bring up at the team's retrospective. There are lots of possible approaches, but the team should decide for themselves.
Some things you might consider:
- The QA shows bugs to the Product Owner before they log them
- If a bug is not viewed as important by the Product Owner, resolve it as 'won't fix'
- Discuss as a team the types of bugs that might not need to be logged
From the QA's perspective it's very important that every bug gets recorded somewhere (either in the backlog or at a different place). While testing it's very impractical if for every finding you first need to analyze whether it's important enough or not - that slows down the testing process, and you risk missing essential bugs (because you confuse them with similar bugs with different underlying causes).
In our team we have had quite a few discussions with regards to this topic, and in the end this is what we decided on:
- Make sure that it's clear for the testers what the stakeholders expect (requirements, things that are out of scope, level of quality, etc)
- Testing activities are guided by a product-risk assessment - the most important parts (high chance of failure, or high impact) get the most attention (this already filters out many non-essential bugs)
- Every issue gets recorded while testing.
- After each significant testing effort, issues are clustered and analyzed. The testers prepare the meeting, the product owner decides on priority (blocking issues get the highest priority)
- High priority issues also get a high ranking on the backlog
- Issues with priority low or lowest rarely get fixed individually; instead they are resolved when related work is done in the same area
This way the boundaries between the different priority classes are transparent for everyone (and can shift over time). Testers are able to log each and every bug, while the product owner hears a summary of their findings and can spend his time on the most important ones.