Skip to main content

Multiple Product Owner in single Sprint sharing common/same developers

Last post 09:58 pm September 22, 2021 by Piotr Górajek
4 replies
07:26 am September 21, 2021


I have a question regarding what if there are multiple services and multiple Product Owner in the same Sprint, sharing the common developers. Is this the correct practice? Or for each Sprint, there should be one Product Owner who owns a bundle of services? And the other product owner should conduct the Sprint separately?


What would be the best way to deal to this kind of scenario?


Best Regards


10:09 pm September 21, 2021

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

The first thing you'll need to figure out is whether or not each service is its own product, or do multiple services role up under one product?

For each product, regardless of how may Scrum Teams work on the product, there is:

  • 1 Product Owner
  • 1 Product Backlog
  • 1 Definition of Done
  • 1 Product Increment
  • 1 to Many Scrum Teams

10:13 pm September 21, 2021

If Scrum Teams start to share developers across products, what do you anticipate the end result might be and how effective will the developers be in that situation?

11:18 pm September 21, 2021

What would be the best way to deal to this kind of scenario?

Establish transparency over any losses due to context switching. There could be an organizational impediment at hand, such as work from disparate sources being pushed onto the team. If there is indeed a problem like this and it is not addressed, the team might end up locally optimizing around it.

09:58 pm September 22, 2021

+1 to Ian and Chris. In your scenario, as close as you can get to assess that there is Scrum, is when each PO and product is treated separately. It will be a little stretch in logic, however, from an isolated point of view, it might look "better".

There is a sentence in the Scrum Guide that may be helpful in your situation to consider:

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.

Depending on how you interpret it, that stretched logic may fall apart or stand still. If we consider it more widely, then it becomes obvious that regardless if it will be treated as "one Sprint" or many "overlapping Sprints", those setups would be far from ideal.

Putting the above aside, IMHO Context Switching that Ian points out should be the focal point of your focus. It most likely not only impact effective time spent at the development, but also introduce a lot of risk for i.e. product quality or people burnout and turnover. Not to mention that Context Switching (or multitasking) is harmful to our health, as we can find in those studies how different variants impact us:

So I would suggest upon introducing more transparency, think about those different dimensions to take a look at.

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.