Skip to main content

Multiple product owners for single team

Last post 12:55 pm October 23, 2019 by ANDREW JOYNSON
6 replies
05:03 pm February 5, 2017

Hi all, first post here.

We have a team of 7 developers.
We are responsible for 4 products and associated tools.
All the products are inter related, so it is not possible to divide in smaller teams.
We have 3 product owners, who represent different types of customers, for different products.
Features and bugs are sometimes cross-product, although sometimes the requirement only comes from one PO, so it is not possible to divide into different backlogs or different sprints.
A sprint can contain issues for the 4 different products, requested by the 3 product owners.

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!


06:15 pm February 6, 2017

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.


08:56 pm February 6, 2017

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.


06:43 am February 7, 2017

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


09:05 am February 7, 2017

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


09:58 am February 7, 2017


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).


10:29 am October 23, 2019

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.