Skip to main content

One Core Team working on Multiple Products with Multiple POs

Last post 03:08 pm March 3, 2021 by Paul Mastorides
5 replies
05:53 pm March 1, 2021

I'm a relatively new SM and have been tasked with overseeing our core 'Platforms' team, which historically has been a team for our own products that members rotate in and out of when not on customer engagements. (A VERY unstable team obviously, with one permanent member) We have decided to now hire a core team of 6, who will be working on 3 products we wish to develop. We use a Scrumban board, have one-week sprints, and there is one Product Backlog containing all the Initiatives & Epics for each product, and different PO's for each. I'm struggling in how I might make the most of this situation, thinking rotation might be my best bet. It doesnt feel like scaled scrum, I want to make sure the engineers are able to achieve the sprint goals and not get silo'd... any suggestions would be appreciated!


08:44 pm March 1, 2021

Pushing 3 products onto a single team will not cause the work to be completed more quickly. Rather, there are likely to be net losses due to context switching. It's better to limit work-in-progress...in other words, to stop starting and start finishing.

Where does the decision to work on three products right now actually come from, and how has this been squared with the availability of just one team? It doesn't sound like a pull-based decision made by team members who understand their capacity.


08:53 pm March 1, 2021

How would a decision be to invest in one product, over another; and who would account for that?

any suggestions would be appreciated!

Focus on enabling empiricism, by providing transparency over the situation and the problems it will cause, along with encouraging inspection and adaptation by those who are in a position to do something about it (that might be team members, stakeholders, other co-workers, or management).

It might be necessary to let a flawed system fail, rather than trying to prop it up, and ultimately masking the underlying problems.


09:13 pm March 1, 2021

+1 to @Ian Mitchell.  This isn't even Scrumban as I know it.  It sounds more like chaos to me.  How are items ordered in this combined Product Backlog?  How do the 6 developers know which items to pull in when they have time?  Who is ultimately responsible for maximizing the value that the development team produces? 

Consider the scenario where you have 1 kitchen that is making food for 3 different restaurants where the menus are constantly changing.  Would you actually consider the service to be great?


11:50 pm March 1, 2021

At least you solved the problem of rotation. A team that frequently changes its composition has a tough time developing and maturing to the point of working well effectively. But another problem (or two closely related problems) were introduced.

Having a Product Owner for each Product does make sense. And, unfortunately, having a team support multiple products is a real situation that organizations face. It's not optimal, but having the three Product Owners can be a setup for spinning out new teams to take over these products in the future.

The biggest issue that I see is the single Product Backlog for all of the products. This is the first change that I'd recommend making. Splitting up the work would help the team order the work associated with each product and identify dependencies. Each Product Owner can be responsible for ordering the Product Backlog associated with their product and they can negotiate with each other to determine which product will be worked on by the team in a given Sprint. The ideal situation would be to focus on one product each Sprint and err on the site of planning goals much less than projected capacity to ensure that there is a clean wrap-up each Sprint should the next one be focused on a different product.


03:08 pm March 3, 2021

What do the PO's feel not having a dedicated team and competing with resources with other PO's?


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.