Clarification on PO Responsibilities vs. Technical Documentation Ownership (SAP-related Bugs)
I would like to believe that I’m not mistaken in this situation. I’m a Product Owner (PO), but we also have Technical Architects in the company who are part of the development team. In addition, we have people from SAP who sometimes get involved during the implementation process or only when bug fixes related to SAP are needed (only when there are bugs; they are not part of the main Scrum Team and don’t work with Scrum or Agile methodologies).
There have been cases where one of the Architects mentioned me in a Jira ticket, commenting that documentation about how the SAP team resolved a bug should be included in the Jira ticket. This is because the SAP team usually doesn’t document their solutions directly in the tickets.
I replied to the Architect that, although I can include some references in the ticket, the SAP team is the main point of contact who should be addressed with the request to provide proper documentation.
I’m not sure what’s right or wrong here—I don’t have much experience as a PO, and I don’t know if we are breaking any Scrum principles. But I feel that some people think everything should be addressed to the PO and expect the PO to resolve everything. The truth is that I can’t be behind everyone, constantly asking them to please document things. I’m also not sure if this is something the Scrum Master should handle instead.
Additionally, I think the developers themselves, in their technical role, should directly ask the SAP team for documentation, since in the end it’s their work that is impacted. If more SAP-related bugs occur, having that documentation would help them in their analysis.
I’m sure there are different opinions on this, and I’d appreciate hearing from experienced POs or Agile Coaches on how this kind of situation should ideally be handled.
It sounds as though SAP documentation or input is needed before certain work will be Ready for Sprint Planning. Without it, the Developers are unable to commit to Done.
Is this information being actively sought during Product Backlog refinement?
It’s a good idea to discuss this with the Scrum Master, and possibly involve the architect. At the very least, clarify with the architect what the strategic intent is—e.g., is there a desire to build internal SAP expertise over time?
Scrum does not prescribe how a PO should engage with external technical suppliers. As Product Owner, you ensure the Product Backlog clearly reflects the work the team needs to do, and include any dependencies on the SAP team. Then the technical resolutions you mentioned, generally fall within the team’s domain. You are not violating any Scrum rules, this is more a practical team-level matter.
A joint session or workshop could help clarify expectations and responsibilities. This could also be raised in a Retrospective, so the team can decide together how to best handle communication, handoffs, and knowledge sharing.
In short: no, you are not breaking any Scrum rules in my opinion. This sounds more like a team issue requiring input from the technical side, and use the Scrum Master to help guide the discussion.
There is not a rule in the Scrum Guide about this in. In fact, I'm not sure there are any rules in the Scrum Guide. I read a lot of suggestions but no rules because it isn't a process or methodology. It is a framework.
Having said that theoretical thing, let me give you my honest answer. This is another example of Scrum being misunderstood and being used as a weapon. The architects are using this as another way to avoid having to take responsibility for talking to any other group and letting you take the blame. I don't know, because you have never said, but I would bet there is someone in the SAP group that is considered on the same level as your architects. Why can't those people have conversations at their level to ensure that this kind of situation is taken care of? You have said that you are a Product Owner. I'm sure that is your job title given to you by your organization. And I'm sure that there is a job description that is associated to that job title. Just as there are job titles of some kind given to the developers and architects which also have job descriptions. I have used that same situation to push back when found in similar situations. What do the job descriptions for the job titles involved say about the work that those people holding the job title are expected to do and be responsible? If they continue to push bureaucracy on you, use it as a response.
Empiricism is the root of the ability to be able to adapt to change quickly (i.e. agility). It involves doing something, evaluating the outcome, and adapting as necessary. I like to use it as a guide to everything I do. If I were in your situation, I'd use the past experiences of the team to help them understand if they are doing things in the most efficient manner. Ask the developers, not the architects, if they feel it would be better to go directly to their SAP counterparts than having you act as the intermediary. Go to the people most impacted by the situation and have them voice their opinions. Then use that as an impediment for change if necessary.