We have situation that our team is making quite a big system. Company has divided parts of system into several Product Owners. So we are working with various Product Owners depending which part of the system we are currently developing. They are coming in and coming out, but each is using our Product Backlog.

Is that situation correct? Or Product Owner should be dedicated into the team and works more or less as a Proxy Product Owner?

  • I would say as with most questions here, "it depends". First, there is no correct or incorrect. As some pointed out, there are rules in formal Scrum, etc. but you didn't frame your question that way. Rather than follow a rule, it's worth asking yourself - what are the pros and cons of the current approach? What other configurations could you try (multiple backlogs, intentional team rotations, etc.), and is it feasible to try some and compare the results? And most importantly, what does the team think and what ideas do they have about trying to improve it? Feb 26, 2016 at 18:00

3 Answers 3


A Product Backlog Must Not Be Managed By Committee

If I understand your question correctly, then no. A Product Owner is solely responsible for the contents and prioritization of the Product Backlog. Multiple POs working on the same backlog has the same effect as a backlog managed by committee. This is not acceptable within a formal Scrum framework.

Instead, these other "Product Owners" should work through the real Product Owner who has been assigned sole ownership of the Product Backlog. These other folks are probably stakeholders, not Product Owners, and should be treated as such.

  • I'd also suggest adding that this protects the development team from too many distractions, since the ScrumMaster can more easily train and coach the Product Owner on what his or her role is with the team. It's easier to coach one person than it is a whole lot of wolves.
    – jmort253
    Feb 24, 2016 at 10:35
  • Either that or there is more than one product
    – Ewan
    Apr 15, 2016 at 17:46

There are two main reasons why a single Product Owner is preferable:

One Voice

A single Product Owner means the delivery team only has to worry about one person's opinions. They get to focus on delivery and do not get distracted by disputes on prioritisation and arguments over the detail of requirements.

The Scrum Team

A Scrum Team consists of a delivery team, a Scrum Master and a Product Owner. When a Scrum Team works together for a while they get to know how each other works. They establish a rapport and often their productivity increases.

Having said this, there are situations where a single, dedicated Product Owner is difficult to achieve. Usually this is when the product setup is such that one product does not keep the team busy all the time. Even in this situation it may be possible to negotiate with the business and get them to nominate a person who has responsiblity for all the areas the team is working in. This is still an orthodox Product Owner role, they just happen to look after more than one product.

One team working with multiple Product Owners is possible, especially if the Product Owners are of the right personality types and have the right attitude. However, it is unlikely the Scrum team will ever be as effective with multiple Product Owners as it will be with just the one.


It's correct that a product backlog shall be normally managed by one Product Owner and not by a committee - this ensures a proper vision and communication between the business side and the team.

But there are cases when one Product Owner is not enough, as when you have a large project (you mentioned it is a big system) and need to scale the process. Not enough means that one Product Owner is not able anymore to grasp an overview of the entire product (or of the backlog) nor to properly interact with the team(s).

A first scaling possibility would be to split the work among more teams (an agile team is small, no more than 8-9 members, because of the communication and coordination overhead). The product backlog remains still only one.

When the teams will be too many (possibly after 7-10 teams) the Product Owner will not be able anymore to work with all the teams or properly detail every item in the backlog. At this point you will need to introduce more changes.

A possible second step would be identify in the backlog major requirement areas and define the backlog with separate views, one for each area, and each one will have a dedicated Product Owner and dedicated teams. These area-backlogs are not separate backlogs but only a different view inside the one Product Backlog.

Note that these areas are organised around customer-centric requirements (really just a coherent fragment of the backlog) more than around product's architecture (like could be a split among different parts of the system) but could be temporary, can change over the lifetime of the product.

The area Product Owners (PO) may be in a Product Owners Team and actively collaborate to deliver the product (Product ROI, joint retrospective, …); for example, before any Iteration Planning the Product Owners Team should meet in a pre-planning meeting so that they can coordinate how the different Area-Backlogs priorities reflect themes at product-level, which PO will take care of common themes such as a common infrastructure, etc.

If this is your case - big system with different areas and teams - you can certainly have multiple Product Owners.

If you have only one team but the Product Owner changes every couple of iterations according to the part of the system being developed, well, this is unusual. You need to ask why this is beneficial: if one team can handle all the parts why cannot one PO? The first Agile principle is inspect and adapt: try and see if there are any benefits or drawbacks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.