Multiple product owners for single team

From your reading of the Scrum Guide:

- how many Product Backlogs do you believe are needed for 4 products?
- how many products can a single team work on per Sprint?

Remember there's nothing to stop a team from working on different products in rotation, as long as they have the skills and each respective Product Owner is in agreement with this practice. Short sprints are typically needed to ensure each product is serviced in a timely manner.

Hi Ian,

I understand the idea of short sprints with rotation, but these products involve a lot of hardware, so short sprints don't work, as tests alone can take more than one week, and part of the tests are done by other R&D teams. We don't release often, for some products we only release twice a year, for others, especially bugfixing, we release once a month.

Maintaining separate product backlogs is also not a good option, as the features and bugs overlap too much.

I understand that this is not the typical or optimal situation to use scrum, but in the real world projects are never simple.

Hi Mike,

why you want to force using SCRUM if it obviously can't work in your case as long you can't change the situation with the PB-issue and multiple POs. I had once some similar situation and by us Kanban was the answer. While SCRUM has some strict rules (without them you won't do SCRUM), the Kanban don't requests to change your development process or roles. There you can have your one backlog with multiple POs, you have the visualization, you can have retrospectives etc. you have in Scrum, but nothing is time-boxed, the cadences are free to change.

Greetings,
Peter

Who in your organization actually wants to use Scrum in this situation, and why?

Posted By Mike Melga on 05 Feb 2017 05:03 PM

I feel that backlog refinement meetings could be more productive, as at some point there is no logic and simple way to decide between priorities.
It is easy to decide if an issue is in the top 20, but not easy to decide if it goes in 14th or 15th place, as it can move another PO's issue down.
Any tips on how to improve this situation? Thanks!

Hello Mike,

I would like to quote here something that Ian posted in an earlier post and which helped me a lot. He explained the rationale behind sprint goals.

"The purpose of framing a sprint goal is to allow a significant risk to be addressed."

You could try eliciting a sprint goal with all the POs in one session. Try coming jointly to an agreement about the most important and urgent risks to be assessed. Do they all agree on the most significant risks?

If you can come to a consensus, then you have your Sprint goal and thereafter the items that should go into the sprint in order to meet this goal. (In any case, they shoud be able to work together right?)

This should ease one of your problems which is decision-making and prioritizing.

Try using them and let us know how it works out.

One word of caution about the division of teams, I read somewhere that if you have too many small teams, then the number of communication channels explodes and communication becomes time-consuming/less efficient than if you had two teams or one large team.(<9 members).

Thank you for all posting this information. I find all this helpful