When scaling Scrum, many of the Scrum Events/Ceremonies need to be run with all programme Teams and, sometimes, all product stakeholders present.

This obviously requires a larger than normal space but the format used is important as well to maximise the VALUE of the ‘workshops’; for example, for a Sprint Review where several Teams are ‘show-casing’ what they have produced, it would be boring for the stakeholders just to sit through multiple presentations and demonstrations especially if there are features being reviewed that they have no immediate interest in.

Scaled Scrum Events/Ceremonies are best run if everyone is co-located or can travel to the Event.  This is not always possible or economical for organisations that have programme Development Teams and stakeholders scattered around the world.

• Overall Programme Scrum Event Process

The overall Programme Scrum Event process is SIMILAR for both non-co-located and co-located Events:

1. All participants attend an opening session where the objectives and specific process for the workshop are explained
2. Depending on the needs of the workshop, all participants may stay ‘together’ for the whole workshop (unusual) or ‘break-out’ sessions may be held that focus on specific workshop topics; anybody may attend a ‘break-out’ session if the topic is of interest to them
3. If ‘break-out sessions are used, then it is usual for all participants to come ‘together’
4. At least once during the Event for ‘catch-up’ and information sharing.  There may be discussion about altering the Event process
5. Toward the end of the Event for ‘catch-up’, information sharing and conclusion purposes

• Non-Co-Located Programme

For non-co-located Teams and stakeholders, use should be made of tele-conferencing and video-conferencing technology.

Scheduling of combined and ‘break-out’ sessions can be difficult if the Teams and stakeholders are in widely different time zones; what would normally be a half-day Event may have to become a full day or even a day and a half.

• Co-Located Programme

For a co-located programme and stakeholders, it is essential that the ‘main room’ is big enough to hold all participants and is equipped with white BOARDS and flip charts.  If the room is really large, then a big screen and PA system may be required

The ‘break-out’ sessions may be held in the same room; some or all may be held in readily accessible smaller rooms.

• ‘Big-Room’ Formats

The detail of how the ‘big-room’ Events may be run and facilitated vary but the 2 most common are Open Space and World Cafe.

The following are how the ‘standard’ Overall Programme Scrum Event Process may be CONFIGURED for specific Events:

• Release Planning

For one-Team Scrum we would only plan a Sprint at the beginning of a Sprint wherever we are in the Release cycle but for a programme, the stakeholders will need to have some idea what will be in the Release and the Teams need to produce outline Sprint Plans so that dependencies between Teams may be discovered, minimized and planned for.

Before the joint planning session, the Programme Manager will have worked with the relevant stakeholders to set a Release Goal and select potential features for the Release ordered by business value.

At the start the start of the Event the Programme Manager may allocate potential Release features to Teams or the Teams can volunteer for them.

The Teams, aided by relevant stakeholders, will go into concurrent ‘break-out’ sessions to decompose the features into User Stories and estimate the total effort required for each feature; this activity should be timeboxed to reduce the risk of the Teams going into too much detail.

The Teams will come together to see each other’s list of User Stories, to identify dependencies and distribute User Stories so that the effort is spread evenly between Teams.

The Teams then go back into ‘break-outs’ and produce an outline Sprint plan for each Sprint in the Release.

Finally, everybody comes together to produce/update the Release Plan Board with the outline Team Sprint Plans to ensure that the highest value User Stories will be developed first and that inter-Team dependencies have been catered for.

• Sprint Planning

Some Programme Teams hold their individual Sprint Planning in the same space but separately and then ‘compare notes’ toward the end of the session to ensure that dependencies have been identified and catered for.

• Daily Scrums

Some co-located Programme Scrum Teams hold the daily Scrums at the same time and in the same space but separately, then each team summarises any highlights to the other Teams.

Other organisations hold their Team daily Scrums as ‘normal’ and the Scrum Masters have their own ‘daily Scrum of Scrums’ at a convenient time.

• Sprint Reviews

A programme Sprint Review involves all Teams and all relevant stakeholders so the large space is needed for a co-located programme.

The workshop starts with the Programme Manager SUMMARISING what has gone on in the Sprint then the stakeholders attend as many Team demonstrations and hands-on trying of functionality as ‘break-outs’, held either in the same space or readily accessible ‘break-out’ rooms.

There are usually white boards and/or flip-charts available for stakeholders to make notes about things that they would like to be discussed toward the end of the Review when everybody comes together again.

The final ‘all-together’ session also includes the Programme Manager asking the stakeholders if there are any features/User Stories that need to be added to the Product Backlog; if there is anything that needs to be deleted from the Product Backlog and if the current ordering is still viable.

For non-co-located Teams and Stakeholders, the individual ‘break-outs’ can be run as concurrent timeboxed ‘webinars’ at scheduled times throughout the Review session; each Team running several ‘webinars’ to allow as many stakeholders the chance to ‘login’.

• Sprint Retrospectives

Although each Programme Scrum Team may hold their own Sprint Retrospective, it is important that a Programme Sprint Retrospective is held.

A Programme Sprint Retrospective follows the Overall Programme Scrum Event Process described above; the opening session is used to identify the good and bad things about how the programme is running and choosing the most important issues that need to be addressed.

Each ‘break-out’ session focuses on one area of issues and any members for any Team attempt to find the root cause of the issue and devise resolution plans.

There may be an interim coming together to discuss progress so far and maybe add to or subtract from the list of issues to be discussed in a second ‘break-out’ session.

During the final coming together, the results of the ‘break-out’ sessions are discussed and plans are devised to resolve the most important issues.