Skip to main content

Multiple scrum teams with one PO and one Master Backlog

Last post 08:41 am March 13, 2015 by Daniel Ionescu
5 replies
06:50 am February 20, 2015

Hi,

I've read a few posts about having a single Master backlog with multiple teams but don't quite go into details about how the meetings are managed, especially with only one PO.

My current situation is this:

My current team in London, has just been added to another team in Scotland. Both teams are currently now one team working from the same Master and Sprint Backlog, with one Product Owner. This is causing all kind of issues as the team is 17 people not including PO and Scrum Master. People aren't communicating well, not bonding etc.

My proposed solution is to break into squads. Have a co-located London team and co-located Scotland team. The issue I am having is that the PO is rejecting this idea. He doesn't like the idea that he would have to now have 2 sets of planning, 2 sets of refinement etc. He believes that he can't split the prioritized work among 2 separate teams and therefor we must be one team - personally I don't think this is an issue. He should now be getting more work done as he has got an entire team given to him.

I can't see any solution other than the PO having to do the work for both teams, or getting a PO for each team.

Does anybody have any other solutions to this or am i right in thinking the PO needs to do his bit for both teams.


10:32 am February 20, 2015

> ...the PO is rejecting this idea. He doesn't like
> the idea that he would have to now have 2
> sets of planning, 2 sets of refinement etc.

If a Development Team becomes too large and chooses to self-organize into smaller teams that are more appropriately sized, then this is their prerogative. They may continue to plan work from a common Product Backlog that has one Product Owner, but would do so into their separate respective Sprint Backlogs.

Since there is only one Product Backlog, the teams may jointly share their Sprint Planning and Product Backlog refinement sessions. They may also need to hold a regular Scrum of Scrums to facilitate replanning and to remove any impediments to the delivery of the jointly produced increment.

> He believes that he can't split the prioritized
> work among 2 separate teams...

That isn't his job anyhow. It is up to the Development Teams to self-organize the work that is needed in order to meet the agreed Sprint Goal.


08:18 am February 27, 2015

From Scrum Guide: "Having more than nine members requires too much coordination." and I felt it working as a SM. So 17 people sounds good for 2 scrum teams.

For better communication is important that people in a team to be collocated.
Tobias Mayer says: “Distributed teams are not teams;.." http://www.energizedwork.com/weblog/2008/07/distributing-teams-is-a-sil…

Each context is different - but I will try to describe my experience - and hope something can apply to your project.

Context:
We are 9 teams in 3 different geographical areas.
We have the same Product Backlog managed in jira and the same PO (in the last time we have 3 ProxyPO)
2 weeks sprints

Our way:
We have only one Sprint backlog in jira and quick filters for each team.

Sprint Planning:
There is only what planning meeting with PO and all the team's representatives.
Topic One: What can be done this Sprint? The stories are moved from Product Backlog to the Sprint Backlog. We have the discussion what team will work on which stories. (1.5 h)
Each team will have: Planning Topic Two: how will the chosen work get done? - Split choosen User Stories into tasks. Come back to the PO is there are questions or there is to less/much work for the sprint (2.5 h)

3 times/week we have SoS (Scrum of Scrums). This purpose of this meeting is a Dev Team co-ordination so the representative should be a technical contributor. Being 9 teams it is important to solve the dependencies between team's User Stories ( Is anything slowing your team down or getting in their way? Are you about to put something in another team’s way?) 1h

Refinement (as needed) - preparing the stories for next sprints
We have stories grouped on epics - and each epic has assigned one team member to be responsible for coordinating his team the refinement for that epic. Usually the team that do the refinement will work on that story on next sprints (but is not all the time possible). Having agreed the same Definition of ready allow us to take stories refined by other teams.


Experiment, retrospect and adapt!


09:11 am March 6, 2015

Hi Pete, I highly recommend reading about LeSS (http://less.works/), which is framework for scale SCRUM and is very similar to what Daniel said. We have 5 teams with 1 Backlog and especially the two phase planning works great for us.
Michal


03:17 am March 12, 2015

Less is great :)


08:41 am March 13, 2015

You can find an interesting article here:

http://blog.scrum.org/know-scale-scrum/

It says that there is a new 2 days training from scrum.org
Scaled Professional Scrum for Practitioners
http://courses.scrum.org/classes/show/2984

The Nexus: for scaling and managing large agile projects:
https://www.scrum.org/Resources/Nexus


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.