Multiple Product Owner in single Sprint sharing common/same developers

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

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?

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.

+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:

• Multitasking is associated with harm to our brains: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4174517/
• Multitasking can lead to increased distractibility: https://www.sciencedirect.com/science/article/pii/S1053811916300441
• Multitasking hurts your grades and the grades of those around you: https://www.sciencedirect.com/science/article/pii/S0360131512002254
• Multitasking increases chronic stress, depression, and social anxiety: https://www.ics.uci.edu/~gmark/Home_page/Publications_files/Millennial%… and https://www.researchgate.net/publication/232926411_Media_Multitasking_I…

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