Can there be multiple product owners for a scrum project?

Last post 05:07 pm July 10, 2017
by Timothy Baffa
8 replies
Author
Messages
05:45 am May 2, 2014

In certain cases, when the scope of development is large, the management is often forced to sustain multiple development teams. This scenario is very common in case of development companies undertaking outsourcing projects and activities, where disjoint or distributed teams carry out the development. In such a scenario, the management may appoint individual scrum masters for each team, and this is practice is accepted by scrum circles. However, the question revolves around the product owner. Just as you have multiple scrum masters, can you appoint more than one product owner in the scrum project?

07:55 am May 2, 2014

Each scrum team is made up of Development team + Scrum Master + Product Owner. If you have multiple scrum teams then you will have multiple Product Owners each managing a subset of the Product Backlog. Ideally you should all be working from a single Product Backlog. You can read further on this at http://www.capgemini.com/blog/capping-it-off/2012/05/scaling-scrum

06:51 am May 5, 2014

As the name Product Owner suggests, you need one Product Owner for each Product (and one Product Backlog). If your Product is developed by multiple development teams, it can happen that one person cannot do this job for all the teams at once. This is when you can think about several "Sub" Product Owners for each team, but you still need one person responsible for the whole product. The books of Larman and Vodde explain this in detail.

03:38 am May 8, 2014

Hi,

Its best practice that one team lead by one P.O. Or best divide the project in smaller sub project and leads these small project with different P.O.

As every P.O have its own style of executing work and interaction level with client / stakeholder. Its a same thing P.O works under P.M.

Thanks,
Kapil
http://scrum-mines.blogspot.in/

09:54 am May 9, 2014

> Just as you have multiple scrum masters, can you appoint more than one product owner in the scrum project?

The short answer is no, because product ownership does not scale in quite the same way as servant leadership potentially can. Multiple Development Teams, each with a Scrum Master, can draw from a single Product Backlog that must be owned by exactly one PO. Although Scrum Masters and Product Owners can work for multiple teams, only the PO has this relationship with the Product Backlog.

However, this means that if a project encompasses multiple products...each of which is represented by a discrete Product Backlog that is wholly owned by a single PO...then you can have multiple such PO's working in collaboration. Whether or not these are separate products from an end consumer point of view is immaterial. What matters is that each increment from each contributing team can be brought together into a potential release of business value.

05:44 am May 23, 2014

In bigger teams / distributed teams, usually a proxy PO concept is applied. Proxy PO works with each team to provide clarification on requirements to the team , support PO in eliciting requirements etc. However final decision on priority and planning should like with PO. However this a risky approach as delivery expectation and what product should do could be different for a PO from a Proxy PO. In such cases this might raise in a conflict. So in such situations, Proxy PO has to be a person who can mirror PO as much as possible and more of a support to team at geographical location so that their productivity is not impacted.

12:40 pm May 23, 2014

The Proxy PO concept is an anti-pattern. Yes, in a product with numerous teams, some Dev Team members will help with PBL mgmt, but none of them should hold the title of "Proxy" because this creates a bottleneck and more handoffs.

Ian's answer above is excellent. If you really want to some good help on scaling, see:
http://www.ScrumCrazy.com/scaling

01:04 pm July 10, 2017

What do you mean by feedback loop

05:07 pm July 10, 2017

The 3 pillars of Scrum: Transparency, Inspection, and Adaptation.   The shorter the "feedback loop" (assess small deliverables/experiments to guide future decisions), the more Agile you become.