Skip to main content

Should the PO be responsible for bug management?

Last post 03:06 pm October 20, 2021 by Daniel Wilhite
6 replies
08:57 am October 20, 2021

Who is responsible for monitoring bug trends, scheduling bug fixes, RCAing bugs?

10:35 am October 20, 2021

If a bug was found during a sprint - Unless your company has specific guidance on fixing bugs, they represent work to be done and should be ordered on the Product Backlog by the PO. Two exceptions are if the work to fix the bug is less than the work to actually log it, or if the bug is so critical that it would be negligent to leave it unfixed.


The PO and Developers could monitor the following key value metrics from the Ability to Innovate key value area: 

Defect Trends:  Measurement of change in defects since last measurement. A defect is anything that reduces the value of the product to a customer, user, or to the organization itself. Defects are generally things that don’t work as intended.

Technical Debt:  A concept in programming that reflects the extra development and testing work that arises when “quick and dirty” solutions result in later remediation. It creates an undesirable impact on the delivery of value and an avoidable

increase in waste and risk.

Production Incident Count:  The number of times in a given period that the Development Team was interrupted to fix a problem in an installed product. The number and frequency of Production Incidents can help indicate the stability of the


Change Failure Rate:  The percentage of released product changes that result in degraded service and require remediation (e.g. hotfix, rollback, patch). For more information, see the DORA 2019 report.

11:27 am October 20, 2021

For bug fixes, the responsibility changes depending on where the defect was found.

If defects are found during the Sprint in which the work is being done, then the Developers are responsible for fixing the defects and getting the work to meet the team's Definition of Done. If there needs to be a tradeoff between meeting the Sprint Goal and release with known defects, then the Developers may want to consult the Product Owner to understand if it's better to not release or release with known defects to get fast feedback.

If defects are found on work that the team has already completed, the Product Owner would be accountable for ordering the work on the Product Backlog. This could also include interrupting the current Sprint to attempt to resolve an issue earlier. The Developers would be involved in refining the reports, which may help the Product Owner properly order them.

Monitoring bug trends doesn't fall to anyone in particular. My suggestion would be that the Scrum Master is in a place to help the team understand what data they have and what they may need to start collecting to be able to answer questions about trends in product quality. The Scrum Master would also be in a place to help the team and external stakeholders figure out what trends would add value to a decision-making process. However, the actual data collection and monitoring may involve any person on the team.

RCAs should be facilitated by the Scrum Master. Since RCAs attempt to get to the root cause, the Product Owner and Developers should be involved in determining the causes, identifying the root cause, and coming up with a plan to prevent future occurrences. In my experience, it's very difficult to participate in an event while also facilitating it. If the team has someone splitting their time between Developer and Scrum Master, it may be a good idea to find an outside facilitator. I'd apply the same suggestions to Sprint Retrospectives, as well.

12:38 pm October 20, 2021

Who is responsible for monitoring bug trends, scheduling bug fixes, RCAing bugs?

If work is not Done the Developers will be accountable for fixing it and assuring quality. Others may undertake certain responsibilities for doing so. The Product Owner may triage repairs on the Product Backlog for example.

02:37 pm October 20, 2021

- The Scrum Guide states that the PO is accountable for "Ordering Product Backlog items". PBI's are not only User Stories, they could be whatever the team deems convenient as, for instance use cases, test cases, improvements, maintenance tasks... and, yes bugs.

- But the Scrum Guide also adds "The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable". As you see there is flexibility on how to manage aspects like bug prioritization depending on what is the more suitable scenario based on the team's context.

- In the case of defect monitoring, the whole Scrum Team is accountable on bringing transparency about what is the current situation of the product. If there is not enough transparency, the Scrum Master must issue this fact to the whole Scrum Team in order to solve it.

- On RCA for bugs, the SM has also a paramount role to facilitate on how to arrive to that root causes.

Hope these answers will be of any help, Niall!

03:02 pm October 20, 2021

Thank you all, this answers my questions.

Another caveat is the Bug management in a scaled environment e.g. 12 teams, 8 SMs. 

Any idea how this would work with the above?

There is a list of Bugs, still unknown which teams should own them, more triaging required, RCA is also an issue i.e. which SM would drive RCA on which Bugs.

Bug trends across the product is increasing but no one seems interested in finding out why and if and how to fix it.

03:06 pm October 20, 2021

I'm going to repeat a response that I use for a lot of the questions here.   The Scrum Team should decide how this is going to be handled.  

I have yet to meet a developer that didn't want to fix defects.  However, they will also be reasonable in the assessment.  They will be forward with their explanation of whether this defect has to be fixed now or could be fixed later.  If given enough information about the business criticality and dependence of the features on which they work, I have found that they make very good decisions.  

I will also say that I define a defect as something that has been released to production.  If an issue is found during the development and is caused by the new development, I don't count that as a defect. It is work done improperly.  There are times that improperly done work could be released and fixed later. But as I said, the developers will usually want to fix that as soon as it is found.  Defects are something that made it into production, whether it was known or not.  At that point every defect is work that is needed to improve the product. The Scrum Guide states this about the Product Backlog

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

I expect you know the rest of what I would type. 

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.