Skip to main content

Including a Proxy-PO in team

Last post 07:20 pm February 20, 2023 by Harshavardhan Chinchore
4 replies
06:06 am February 17, 2023

Dear fellow scrum practitioners, 

I serve as a scrum master for a team and have a situation. My PO is planning to bring in a new member in team for supporting his PO responsibilities especially around product validations . Although I understand and accept the fact that PO can delegate part of his responsibilities while remaining accountable for them, I sense risk that this role might create confusion for team members as to who should the team reach out for requirement clarification and getting feedback. Additionally, I can foresee that activities related to tools update might get delayed as well.  To make things worse, there is no written and clear communication on which responsibilities will be delegated to the new member. 

As a risk mitigation measure, I am thinking of having a RACI prepared and aligned with the PO and the new member, so that there is clarity on responsibilities. Additionally, I believe this member is a "developer" in terms of role, who will be bound by our team agreement. Is it correct? 

I know a documented RACI in scrum is a contentious topic , but what else can be good and effective ways to handle this situation which are within scrum framework?

Any suggestions are welcome!



11:52 am February 17, 2023

From what you describe, it doesn't sound like you are introducing a Proxy Product Owner. In my experience, Proxy POs are situated between people with decision-making power about a product and people with the knowledge and skills to build the product. They may own the backlog but have no ownership of the product or the delivery of value. In your example, though, it seems like the Product Owner has ownership of the product, the accountabilities described in the Scrum Guide, and the responsibilities associated with product management.

Product management is a broad field and rarely does one person have the time and requisite knowledge to carry out all associated work. Personally, I think that this is one of the areas where the Scrum framework is extremely weak. It doesn't acknowledge the breadth and complexities of product management. Bringing in additional people to help with specific product management tasks and share the workload is often a good thing that can benefit the teams, the development organization, and the stakeholders. Nothing in the Scrum Guide prohibits a team of people to support the various product management functions. These people are also not necessarily considered Developers unless their work results in creating some aspect of a usable product Increment during the Sprint. The only rule in Scrum is that there is a sole accountable individual for work such as managing the Product Backlog, developing and communicating the Product Goal, creating and communicating the Product Backlog Items, ordering the Product Backlog Items, and ensuring that all stakeholders have visibility and transparency into the state of the Product Backlog.

Based on your description, I'm not seeing a significant risk for confusion. However, if you, the Developers, or the Product Owner think that there may be confusion, clearly specifying when the team would go to the current Product Owner first or when the team would go to the new person could be helpful. You don't need a formal RACI matrix. If the Product Owner can enumerate all the things that they do for or with the team, they can decide if they should be the primary person doing those things or if the new person should be the primary person doing them. Delegating doesn't remove the Product Owner's accountability, though.

01:24 pm February 17, 2023

I know a documented RACI in scrum is a contentious topic , but what else can be good and effective ways to handle this situation which are within scrum framework?

I wonder if that matrix wouldn't handle the situation so much as cover it up.

The Product Owner remains accountable for value, even if they have delegated certain responsibilities. Perhaps the RACI matrix would establish something else instead: the normalization of the real risk you have identified, and the illusion of managing it, through the auspices of a traditional management artifact.

I'd suggest that, in Scrum, a clear-eyed understanding of accountability ought to be enough.

03:32 pm February 17, 2023

I share @Thomas' opinion about Product Management being a complex thing.  But as he said, Scrum only states that there needs to an individual responsible for what is defined.  For me this is to help with ambiguity. That statement alleviates the "rule by committee" that so often slows down software development and important decisions.

I often work where the people that participate in the Product Owner responsibility have titles like Business Analyst, Architect, Lead Engineer, User Experience Engineer, DevOps Engineer, and many others.  Depending on the product that you are maintaining, there could be a number of disciplines that would contribute to the requirements or needs.  I have yet to see that there has been confusion in a team because of this. We ultimately know who is responsible.  But if the Product Owner has delegated some responsibilities, we trust that person will be communicating with the Product Owner. 

I can appreciate your concerns but at this point, that is all they are....your concerns.  You do not know if it will cause confusion so all of the work you are suggesting could be for naught.  I suggest that you let the Scrum Team decide if there is an issue.  That would mean that they proxy comes in and work begins.  If an issue arises, it can be discussed in Retrospectives, inspected and adaptation occurs as necessary.  Remember that as a Scrum Master, you are leading by example.

06:04 am February 18, 2023

Thanks @Thomas, @Ian and @Daniel for the responses. I see the PO, who is accountable person in this case, has to make the responsibility split clear for the team. 

@Ian : Well said. However, I don't see any harm in getting things black and white, and if the RACI is making things transparent. 

@Thomas : I acknowledge that the scrum guide doesn't stop anyone having these supporting role and do respect their importance in product development. However, it is also clear that scrum guide is deliberately not explicit in defining how these roles will be accounted for. 

I see two options : The new role is a part of scrum team, bound by the working agreement, and the deliverable is estimated and delivered as part of overall commitment. 

Option 2 : Proxy supports PO externally, and the deliverable becomes a dependency. The challenge in this way is that IF the task is validation for a story/PBI, it might become an impediment in between the sprint.  Note that I am being practical here and considering people in these roles supporting multiple projects. 

I know I might not be thinking within the rules of scrum. Please help me correct my understanding. 

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.