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 (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 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.
Share It With Your Colleagues and Friends to Help Them Learn:
What Is Multi-Team Coordination And Planning? This Might Surprise You!
|
|
|
|
|
|
|
SCRUM INSTITUTE™
