Multiple Product Owner in single Sprint sharing common/same developers

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

Hi,

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

Haya

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.