Scrum Institute, Scrum Framework Episode #15 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org
You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play.
Listen to Scrum Institute Podcast on Apple
Listen to Scrum Institute Podcast on Google Play
Listen to Scrum Institute Podcast on Spotify
Listen to Scrum Institute Podcast on Listen Notes
Listen to Scrum Institute Podcast on Castbox
What Is Multi-Team Coordination And Planning? This Might Surprise You!
Scrum of Scrum
After having seen the last chapter of this course, the next logical question in your mind could be how you do coordinate those different Scrum Teams. So they do work together efficiently.
That’s a fair question, and we have attempted to cover this answer too.
Scrum of Scrum Meetings
Scrum of Scrum Meetings resemble Daily Scrum Meetings. And yet, here during Scrum of Scrum Meetings, the focus is not the work of individual Scrum Team members, but the Scrum Teams themselves.
Scrum of Scrum Meetings do take place every day, and they are limited (timeboxed) to 15 minutes too. And yet depending on the complexity of the project, especially during its early stages while Scrum Teams are just forming, these meetings can take 30 to 60 minutes. That’s totally fine as well.
Common Sprint Review Meetings
Common Sprint Review Meetings with the participation of all Scrum Teams are not mandatory, but they could be very beneficial. Note that Common Sprint Review Meetings do not replace Sprint Review Meetings the Scrum Team conduct locally.
- What did the team do yesterday?
- What is the team planning to do today?
- Are there any impediments to hinder or slow down the progress of the team?
These answers should obviously cover the user stories and interdependencies, which impact other teams too.
The Chief Scrum Product Owner and the Lead Scrum Master can jointly moderate Scrum of Scrum Master meetings.Alternatively, one of them can take over the moderation duty of these meetings, or they can choose to rotate this duty among themselves as well.
Common Sprint Review Meetings
Common Sprint Review Meetings with the participation of all Scrum Teams are not mandatory, but they could be very beneficial. Note that Common Sprint Review Meetings do not replace Sprint Review Meetings the Scrum Team conduct locally.
The participants of Common Sprint Review Meetings are the delegates from Scrum Teams and/or their respective Scrum Product Owners.
The Scrum Teams can also rotate their delegates based on their preferences. The Lead (Primary) Scrum Master carries the responsibility of moderating a Common Sprint Review Meeting.
Common Sprint Review Meetings enable all Scrum Teams to demonstrate their Shippable Product Increments to the Chief Scrum Product Owner and all other Scrum Product Owners.
In this way, the Common Sprint Review Meetings fulfill two purposes:
- All Scrum Teams are now aligned about the current status of the overall project.
- All Scrum Teams collect feedback for their work, and they have the chance now to take this feedback into account, while they do their upcoming Sprint Planning Meetings.
Common Sprint Retrospectives
Similar to Common Sprint Review Meetings, Common Sprint Retrospective Meetings are not mandatory, but they could be very beneficial.
Note that Common Sprint Retrospective Meetings do not replace Sprint Respective Meetings the Scrum Team conduct locally.
The participants of Common Sprint Retrospective Meetings are the delegates from Scrum Teams. The Scrum Teams can choose to rotate their delegates based on their discretion.
Common Sprint Retrospective Meetings are led by the Lead (Primary) Scrum Master. These meetings aim to find out and act on improvement potentials about how the larger Scrum project organization uses the Scrum Framework.
All issues which require the attention and collaboration of multiple Scrum Teams to resolve should be highlighted in these meetings. Their paths towards resolution need to be planned, scheduled, and followed-up.
Multi-Team Planning: The Global Scrum Product Backlog
When working with multiple teams, it is essential to manage a Global Scrum Product Backlog, which contains the user stories of all Scrum Teams. The Chief Scrum Product Owner could govern the Global Scrum Product Backlog. Yet, its contents are maintained by all Scrum Product Owners.
Team-Specific Backlogs
When necessary, the user stories from the Global Scrum Product Backlog can be broken down into more team-specific user stories.
These more detailed user stories are maintained in a Local Scrum Product Backlog. References 99 from Local Scrum Product Backlog to Global Scrum Product Backlog should be present. These references will help the Scrum Teams to see what roles their user stories play in the bigger picture of their project, and what kind of client value they’re delivering.
Sprint Scheduling
In a distributed Scrum project environment, there are two options for how you can choose to synchronize the work of different Scrum Teams.
- Synchronous Sprints
- Asynchronous Sprints
The first option is to use Synchronous Sprints. With Synchronous Sprints, all teams start and end their Sprints on the same day.
Synchronous Sprints are usually the preferred approach since they make communication and coordination of the Scrum Team relatively easier.
Synchronous Sprints
Another option is to use Asynchronous Sprints. With this option, the Sprints do not start and end on the same day.Using Asynchronous Sprints has the advantage that not all Scrum Rituals of individual Scrum Teams must take place on the same day. So it makes for the Chief Scrum Product Owner and other Scrum Product Owners possible to participate Sprint Planning, Sprint Review, and Sprint Retrospective Events of other Scrum Teams and support them when they’re asked to do so.
When one team provides services to other teams, asynchronous Sprints bring an additional advantage.
Asynchronous Sprints
Here is a great scenario to clarify this, which was depicted on the above sketch: The work of TeamA (Supplier Team) needs to be integrated into the deliverables of Team-B (Master Team). With the help of Asynchronous Sprints, Team-A can close its Sprint before the Team-B does. So, Team-B (Master Team) can pick the deliverables from Team-A (Supplier Team) and integrate them into their work before they close their own Sprint.
Effort Estimations
All Scrum Teams within the distributed Scrum Project Environment need to use the same unit (Fibonacci Numbers or Shirt Sizes, etc.) to conduct their estimates.
Similarly, the Global Scrum Product Backlog should adhere to this agreed unit of effort estimations too
Special attention needs to be paid for the estimates of Component Teams. Components Teams do usually provide services for the user stories of Feature Teams. Therefore, they should be getting the necessary support and clarifications during their own Sprint Planning Meetings and estimations.