Scrum Forum
2 Product Owners sharing 1 dev. team
How common is it for there to be 2 PO's (responsible for different products) that "share" one engineering team?
How effective is this?
This statement comes from the Scrum Guides section that describes the Scrum Team.
The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Those three entities are not job titles so if your organization is using Technical Program Managers to fulfill the Product Owner role there is no problem.
I have never seen a situation where one group of Developers were able to successfully work on two products under the influence of two Product Owners. I have experienced a single Product Owner work with more than one group of developers to support a single product. Having anyone split their focus across multiple products has resulted in conflicts in prioritization and loss of productivity due to context switching. I'm taking the fact that you are asking this question to imply that you are already encountering difficulties.
How common is it for there to be 2 PO's (responsible for different products) that "share" one engineering team?
Unfortunately this is more common that it should be. However, I have never personally experienced or witnessed it to be successful.
Hello Eric,
it might be late to add my 5 cents.
My suggestion would be just to play this game as described here to understand what happens in your environment.
https://www.scrum.nl/blog/the-power-of-focus/
And after that to decide whether what you practice really help your developers, and if they are able to work efficiently.
Best Regards
Alex
Agree with the previous advice and comments about loss of focus and context-switching.
Changing this dynamic certainly doesn't happen overnight, but one change/experiment you may want to try in the interim is to periodically meet with this other TPM and agree on which of you can "have" the engineering team for the next 1+ sprints. It is better to not have the team work on both products in the same sprint, since that increases the likelihood of splitting the team into two.
Such an approach supports focus, and reduces the capacity drag of context-switching. However, it is still not the best solution, which would be to identify a second engineering team dedicated to support the 2nd product.
Good luck!