5

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?

Improve this question
1
  • It sounds like a disconnect between QA and the PO in terms of acceptance criteria. They should both agree on what constitutes "done."
    – Pedro
    Mar 6, 2017 at 17:18

3 Answers 3

Reset to default
6

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
Improve this answer
1
  • 2
    +1. Always default to "ask the team." If they push back and want to log bugs anyway, remind them it's the the Product Owner's responsibility to manage the backlog and that the PO's decision's must be respected. Last nuance, the dev team owns the quality, so if bugs are important enough, they are obligated to try their best to persuade the PO of their importance and inclusion in the product backlog.
    – jason.t.knight
    Mar 6, 2017 at 22:12
1

I would suggest that you fix all issues for new stories without going to the product owner at all. If you are constantly creating bugs and not fixing them, this is a sign of a quality problem. I am sorry to say so, but if you do this long enough, you will end up in a lot of trouble.

Improve this answer
6
  • Wouldn't it traditionally be up to the Product Owner to make the call as to whether it's a bug or not? In a lot of these cases, the Product Owner (and Engineers) don't see the issues as bugs at all.
    – Brian David Berman
    Mar 6, 2017 at 0:13
  • 1
    Not necessarily @BrianDavidBerman. Some teams take on a "zero known bug" policy and treat it as a matter of engineering and quality.
    – RubberDuck
    Mar 6, 2017 at 9:57
  • @RubberDuck Any reading on this subject in the Agile community? All my research/practice has suggested that the Product Owner is the gatekeeper for what the team works on. They consider the rest of the team's opinions however it's up to them in the end.
    – Brian David Berman
    Mar 6, 2017 at 14:12
  • @BrianDavidBerman I would suggest that you make "zero defects" part of your Definition of Done (agilealliance.org/glossary/definition-of-done). That's how you don't have to go to the PO for decisions whether to fix a bug or not.
    – Mita Ka
    Mar 6, 2017 at 17:03
  • 1
    "All my research/practice has suggested that the Product Owner is the gatekeeper for what the team works on." -- this is true as far as New Features are being concerned. The team is responsible to deliver quality product, which does not necessarily include the PO.
    – Mita Ka
    Mar 6, 2017 at 17:04
1

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:

  1. Make sure that it's clear for the testers what the stakeholders expect (requirements, things that are out of scope, level of quality, etc)
  2. 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)
  3. Every issue gets recorded while testing.
  4. 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)
  5. High priority issues also get a high ranking on the backlog
  6. 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.