Scrum Guide and Scaling: Part 3 - The Scrum Events

• Scrum Guide and Scaling: Part 1 - Scrum Theory
• Scrum Guide and Scaling: Part 2 - Scrum Teams
• Scrum Guide and Scaling: Part 3 - Scrum Events
• Scrum Guide and Scaling: Part 4 - Scrum Artifacts

Compliance with the Scrum events does not exclude the possibility that other meetings may be necessary. In case of  doubt, in a scaled Scrum implementation a procedure should be chosen in which you can make do with the defined Scrum meetings.

3.1 The Sprints

What is true for a single Scrum team, applies also to a scaled product organization using Scrum. This is particularly important for planning the Sprints.

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints best have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

In cases where several Development Teams work simultaneously on a product it means that their Sprints are also of equal duration to achieve a common inspection and adaptation rhythm. This doesn’t contradict to the often used practice  to complete several Sprints in certain teams, while in others only one sprint is completed in the same time, as long as the Sprint cycles are in harmony.

Whether one now says that several simultaneously developing Scrum Teams have several Sprints or just one sprint is just hairsplitting. At the end of each full sprint all the teams jointly produce a product increment according to the definition of "Done" and the requirements of the organization.

Image 1: Global Sprint for all

Image 2: Synchronous faster Sprints

3.2 The Sprint Plannings

In the Sprint Planning work for the next Sprint is planned. This plan results from the collaborative work of the entire Scrum Team. 

The collaborative work of the entire Scrum Team focuses on two main topics of the Sprint Planning. 

• What can be delivered in the Increment resulting from the upcoming Sprint? 
• How will the work needed to deliver the Increment be achieved?

The first point can be cleared mainly due to the interaction with the Product Owner. For the second point suffice the Development Team alone. There are several possibilities for a scaled Scrum implementation.

3.2.1 Topic 1: What

The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.?

If multiple Scrum Teams plan together the upcoming Sprint, mutual transparency and independent "pull" -based prediction must be maintained the same way as with a single Scrum Team. The following procedures illustrate possible implementations of this rule. 

• Some Scrum Teams jointly organize a first part of the Sprint Planning, where they clarify with each other and with the Product Owner, which Product Backlog items will be implemented by which team in the next Sprint. 
• Some Product Owners prepare a pre-selection of the appropriate Product Backlog items. In this case the assignment is no longer necessary and it's all about the amount of the Product Backlog that will be implemented.

At the end of the Sprint Planning all should definitely have an understanding of all the current forecasts, Sprint Goals (the Sprint Goal) and, if necessary, of the mutual coordination needs.

3.2.2 Topic 2: How

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

Development of the Sprint Backlog thus happens whithin a Development Team. However it must be ensured that during the Sprint Backlog Planning multiple development teams communicate with each other to be able to plan the joint delivery of the product increment.

3.2.3 Sprint Goals / Sprint Goal

The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

If there is a Sprint Goal for the Sprint of a single Scrum Team, there is also a Sprint Goal for the Sprint in the scaled Scrum. According to the description, the Sprint Goal for several teams can be considered as the sum or summary of the Sprint Goals of all the teams. Or the other way around: the Sprint Goals of the individual Scrum Teams are parts of the overall Sprint Goal.

Thus, the overall Sprint Goal is a kind of mini-vision for each Sprint, which serves as an orientation for all the Scrum Teams. Therefore applies – the same as with a single team  - that the Sprint Goal is more important than the particular Product Backlog selection for the Sprint. A Scrum Team that has finished all the selected items, in other words has fulfilled its prediction to 100%, but has missed an important opportunity to help the other teams in achieving the overall Goal has perhaps not yet understood the spirit of Scrum.

3.3 The Daily Scrums

Understanding the Daily Scrums in the scaled environment will probably be better if we do not focus on the mechanics, but the meaning of the Daily Scrum: 

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.

Of course, this self-organized inspection and adaption is done separately in each development team. But exactly this way works also the cross-team synchronization: self-organized, with regard to the Sprint Goal, with full transparency about the development status, progress and common obstacles.

Possible implementations of this rule in scaled Scrum are: 

• Establishment of a separate Scrum of Scrums meeting, in which representatives of the different Development Teams synchronize regularly with each other.
• Exchange of visits in the Daily Scrums - as the meetings are open to visitors - to gather information and share obstacles, requests for help or offers.

3.4 The Sprint Reviews

The Sprint Review is one of the three major inspection and adaptation points in Scrum. Therefore, from the study of the Scrum Guide results, that in addition to the review of the product increment there also must be given the opportunity of feedback and collecting ideas.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.

A Sprint Review must enable the entire product organization to gain this transparency about the current status, to identify and address improvements, changes and opportunities. This typically requires the participation of all the Scrum Team members of all Scrum teams.

For organizational reasons, for larger scaled Scrums a multi-staged relisation of this inspection and adaption may be necessary. However, in too large Scrums there is a risk of losing important information in the transition / scaling. To avoid this, the inclusion of the largest possible group of participants (all) in as few Sprint Review meetings as possible (one) is recommended.

3.5 The Sprint Retrospectives

The purpose of the Sprint Retrospective is to: 

• Inspect how the last Sprint went with regards to people, relationships, process, and tools; 
• Identify and order the major items that went well and potential improvements; and, 
• Create a plan for implementing improvements to the way the Scrum Team does its work.

In relation to a scaled Scrum implementation it means to extend this inspection to the product organization as a whole. In the scaled environment of course you also want to improve the work within the individual Scrum Teams. In addition however there must be established possibilites for the feedback and learning cycles that allow continuous improvement of the used scaling practices and procedures.

There are many ways to scale the Retrospectives. So you can realize Retrospectives with several teams simultaneously - or collect the results of individual Retrospectives at a higher level and use them as input for a "Scrum of Scrums" -Retrospective. The more honest and eager to learn a product organization is, the steeper the corresponding learning and progress curve will be.

... The next article is about Scrum Artifacts. ...