Am I Responsible as a Product Owner for Finding the Initial Requirement of a Bug?
I am working within a process defined by those who have been in the company for years, and I do not agree with it. The development team, especially the team architect, told me that I am responsible for finding the initial requirement (die initiale Anforderung) every time the business reports a bug.
Unfortunately, the software we manage has been handled by different service providers over the years, and some of them did not document everything they were supposed to. I have never been able to find the initial requirement. The architect tells me to look for it in JIRA, but even then, if we don’t find it, we mark these tickets as obsolete and ask the business to create a new user story—or I do it myself.
To me, this seems like a cumbersome process that doesn’t make much sense, since bugs can arise in other ways and should not always depend on an initial requirement.
If anyone could share their experience as a Product Owner or give constructive feedback on whether it is valid for a PO to be responsible for identifying the origin of a bug, I would appreciate it.
For context, I am new to the company compared to the development team, which has been working on this software for years.
Technical debt is cumbersome. The job of making it transparent should not be. Obfuscations about "bugs" and "original requirements" are best put to one side. There is work which remains to be Done, and the Product Backlog ought to tell the truth about that.
What the Developers should care about is the Definition of Done. If the DoD is allowing defective work to make it's way into an Increment, then that's what they ought to be fixing.
Hi Ian, thanks for your comments, but that does not answer my question. Am I responsible as PO of finding the initial requirement of reported bugs?
This is not something that the Scrum framework addresses. The framework does not identify Product Backlog Items as bugs, stories, enhancements, etc. It states
The Product Backlog is an emergent, ordered list of what is needed to improve the product.
There is also nothing said about the need for finding any source requirements. The intent of the Product Backlog in the Scrum framework is to be a place where anyone can go to see what work is needed to improve the product. Whether that is fixing a known defect, adding new functionality, upgrading infrastructure, or adding a new logo because the company has changed. "Initial requirements" are not even mentioned.
This is something that your organization has put in place as part of their process. So, if this is something that is defined by them, then this would be something you need to do. Now, I do not really see any value in doing it because if there is a problem with the product that is causing the stakeholders/users issue, then it should be addressed regardless of why or how it is there. But the true answer here is that the Scrum Guide says nothing about it but it does not dictate process. It provides a framework upon which you can build your own.
Based upon your other posts, I honestly believe that the "Scrum" that your organization has in place is using some of the terms from the Scrum framework but isn't really using the benefits that the framework provides. Good luck.
The Scrum Master said that the development team is being monitored and mensured by the number of changes and bugs they have to solve, so the IT needs it for the KPIs. Especially a business team is used to create bugs where there are no bugs.
I wish there was an active Community of product owners to interchange experience. I could not find any, not even via Meetup.
The Scrum Master said that the development team is being monitored and mensured by the number of changes and bugs they have to solve...
This statement supports my theory about the organization not using the Scrum framework. The framework encourages that delivered value is the most important thing. If a team is being measured by the number of items in their backlog, what is to stop them from creating things there for no reason? I know, "my team wouldn't do that". But I have seen it happen. In fact, I actually helped a team do it so that we could prove a point. We were the top team because of the amount of things we had in our backlog and the amount that we resolved. But if you actually looked at the items we were completing, a lot of them were "check in code", "schedule a happy hour", "discuss that thing that Brad saw on TikTok", and my favorite "eat lunch". (We did that one 10 times in every 2 week sprint).
If you are able, it would be a good idea to have a lot of the Scrum Master, Product Owners and as many "managers" as you can read the Evidence-Based Management Guide (https://www.scrum.org/resources/online-evidence-based-management-guide) that is provided free of charge here. It won't solve all of your problems but it might help others realize how much they don't understand.
No, I don't believe the Product Owner (PO) is responsible for finding the original requirement or the root cause of a bug. The PO's role is to define how the functionality should work so that the development team knows how to implement the fix.
I understand that there may be an interest in identifying the root cause of bugs, but it's important to ensure that this process does not become counterproductive or a waste of time.
No, as a Product Owner, you’re not responsible for finding the initial requirement of a bug. Your role is to prioritize it, clarify its impact, and ensure the team has what they need to address it effectively. The initial discovery and technical investigation typically fall to the development or QA team.
I've been thinking about this, and I'm struggling to understand the value of finding the "initial requirement" associated with a defect. I can think of many reasons why it would be very time-consuming to try to find the initial requirement, and I can't think of a way to justify spending that time.
One situation that could make it difficult is where you describe how different tools were used over time. Information can get lost or misplaced during tool migrations, and you may not realize it. Even if you had detailed requirements in the tools that you were using 3 or 4 tools ago, how do you know that it was successfully migrated? Even if you did some data integrity checks after migration, you probably didn't check to ensure 100% migration, but rather just enough checks to give you confidence based on the amount of time that could be justified.
There's the other case where there was no requirement. Unfortunately, people do build functionality without an explicit requirement. And even if there are requirements, some edge cases may be undefined behavior. If you don't have an explicit requirement or users rely on undefined behavior, you won't be able to trace the defect to the requirement it violates. In other cases, the bug could be missed and then become an expectation.
In most contexts, I don't think it's appropriate for the Product Owner, or anyone else, to be expected to find the source of a defect. I'd instead invest the time in determining if the reported defect is a defect, clearly outlining the expected behavior, and then fixing it. Where appropriate and possible, I'd also expect root cause analysis to explore how the defect was injected and ways to build detection and prevention into the process.