Multiple scrum teams with one PO and one Master Backlog
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.
> ...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.
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.
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
We have only one Sprint backlog in jira and quick filters for each team.
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!
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.
Less is great :)
You can find an interesting article here:
It says that there is a new 2 days training from scrum.org
Scaled Professional Scrum for Practitioners
The Nexus: for scaling and managing large agile projects: