---

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 coordinate those different Scrum Teams so that they 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-Scrums is an optional coordination practice, not an additional formal Scrum event. Teams may choose a daily 15-minute timebox; when the context requires more coordination, a 30 to 60 minute session is another example. They should inspect whether the format is useful.

Example Coordination Questions

• 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.

In the historical coordination pattern described here, a Chief Scrum Product Owner and Lead Scrum Master may jointly facilitate Scrum-of-Scrums meetings. These are optional organizational titles, not additional Scrum accountabilities. 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 teams must still fulfill the purpose of the Sprint Review. Teams working on one product inspect their integrated outcome together with stakeholders; separate local sessions are not a compulsory duplicate event.

The participants of Common Sprint Review Meetings are the delegates from Scrum Teams and the Product Owner accountable for their shared product. Stakeholders also participate in inspecting the outcome.

The Scrum Teams can also rotate their delegates based on their preferences. A designated facilitator, such as the optional Lead Scrum Master in this example, can help the common Review be effective.

Common Sprint Review Meetings enable all Scrum Teams to demonstrate their Shippable Product Increments to the accountable Product Owner, supporting product contacts, and relevant stakeholders.

In this way, the Common Sprint Review Meetings fulfill two purposes:

1. All Scrum Teams are now aligned about the current status of the overall project.
2. 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 Retrospectives that each Scrum Team needs to hold.

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 Retrospectives may be facilitated by a designated coordinator, such as the optional Lead Scrum Master in this example. 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 (See more about 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 multiple teams work on the same product, they share one Product Goal and Product Backlog under one accountable Product Owner. This lesson calls that shared view the Global Scrum Product Backlog. Supporting product contacts and teams may help refine its contents, but accountability remains with that Product Owner.

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 details can be maintained in team-specific working views and, once selected, each team’s Sprint Backlog. Such views refer back to the shared Product Backlog rather than becoming independently prioritized Product Backlogs for the same product. 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. This can make it possible for the Product Owner and supporting coordination contacts to participate in 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

Teams may choose a common sizing convention, such as Fibonacci-style points or shirt sizes, when that helps shared planning. Scrum does not require it, and a point or Velocity from one team is not automatically comparable to another team’s.

Where a common convention is useful, apply it consistently in the shared Product Backlog while retaining the Developers’ responsibility for sizing.

Special attention needs to be paid for the estimates of Component Teams. Component Teams 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.