One Scrum team for multiple products VS One Scrum team per product
Hi,
I am working for the eCommerce division of a large international company, and we develop an enterprise eCommerce solution for our internal clients. Our portfolio is made of multiple products that we work concurrently, at the moment 2 big products and one small. I am managing the dev team of 8.
We started to implement Scrum a couple of month ago on one of the product, and being successful, I now want to use it across all our products. IMO, it would be good to merge all product backlogs into the sprint backlog when we prepare our 2 weeks sprint and use our entire dev team to work on it. During the planning meeting, our product owners can decide how much of each product backlog we put in the new sprint. I like the idea that the knowledge across our products is shared among team members, and the flexibility of being able to increase our effort where needed. For example, in a sprint if there are a particular issue on one product, the entire team can help solving it.
Maybe the organisation of the work between team members might be slightly more complex due to the size of the team and backlog, but I think the benefits totally worth this additional complexity.
However my manager thinks sharing so much knowledge among all team members is a waste of time, and think that having isolated teams will be more efficient, and that we would get more done (he already thinks that having everyone in the team part of the planning meeting is waste of time).
Can I have your thoughts ?
I have worked in this scenario as a Product Owner, as well as a Coach. I have seen it work in some instances, as well as some of the major pitfalls.
From what I’m reading, every product being built is internal to the Organization. Can you also confirm that this is a group of internal employees? Are the other Teams working outside of Scrum in delivering software?
Knowledge sharing is not a bad thing. I would question or address some of the other potential concerns. E.g. --
POs vying for their work first
Forecasting models and predictability will get skewed
Context Switching
.
.
.
I could go on, but I feel you’ll need bottom-up consensus and check whether people are willing to try an experiment? I have seen extremes and would advise to keep the Teams separate, yet find other ways of maintaining cross-functionality.
I can also consider where this may work when you’re scaling a multitude of products and Teams. Feel free to connect via LinkedIn or a conversation (US Eastern Time Zone).
> During the planning meeting, our product
> owners can decide how much of each
> product backlog we put in the new sprint
In Scrum, it is the Development Team who decide how much work they can accommodate in their Sprint Backlog. They would negotiate a Sprint Goal that is of value to a single, clear Product Owner. The Sprint Backlog would constitute the forecast of work needed to meet the Goal and to provide the Owner with a product Increment.
The Scrum Guide makes it clear that a Scrum Team must have one Product Owner and that product ownership is not a committee. If this rule is not observed then Scrum is not being followed and the associated controls are not being applied. How would the Development Team collaborate, during the Sprint, if they are drawing work from two separate Product Backlogs? To which Product Owner would the Increment be provided, and which Owner would be accountable for the release of value to stakeholders?
First, thank you for your reply, really appreciate it.
If I understand well, you guys advise to have one team per product. But we are small company, 8 people in the dev team, which mean if I split my team to have one scrum team per product, and we might work on 2 or 3 product at any point in time, I will have team members part of multiple scrum teams. Those team members will have competing priorities, how can I help them manage those priorities ?
> But we are small company
In your first post you said it was a "large international company", not a small one.
Why not have the team work in shorter sprints which alternate between Product Backlogs? As the PO you can determine which backlog is addressed in the next Sprint. That should be a value-based decision regardless of company size.
Ok well the mother company is huge, but the eCommerce division is small :)
The idea of alternating product sprints is appealing, my team would really be able to focus on one product every sprint ! and our stakeholders would still get value often.
I can already see my manager hiss at the idea of not working on a product for a full sprint, I will have hard time convincing him it's a good approach !