3 Steps to design the Sprint Review of Scaled Scrum or Nexus

The following is my own experience, any feedback or input will be appreciated.

Theoretically, the Integrated Increment delivered by the Scaled Scrum Teams is much larger than the one delivered by a single Scrum Teams. Regardless how many Scrum teams collaborate to development a Product, the time-box of the Sprint Review is the same. I may not be possible to show all completed work in detail.

During the Sprint Review, the entire Integrated Increment is the focus for capturing feedback from stakeholder, it is neither a status report nor an UAT meeting.

My preference is to move the event from one of “verification of functionality” towards one of “delighting our users”. That means we would have a road show for the stakeholders and any other key men invited by the Product Owner at the end of each Sprint.

Our Sprint Review consists of three parts: (4 hr time-box)
1. Demo the key features to delight the attendants. (1~2hr)
2. Open discussion and detail features demo by individual team at different group. (1 hr.)
3. The Scrum Teams and Stakeholders collaborate on the next things that could be done to maximize value like the standard Scrum Sprint.

The first part is very important, especially if you need more budget for the upcoming Sprint.
The Scrum Teams must collaborate to confirm what will be demo during the Demo Show to capturing feedback from stakeholders and to delight the attendants.
I will share my experience in 3 actionable steps as follows.

Step 1: T-Model filter

This is to filter out some similar demo/test. For example, we don’t need to demo the amount limit, expired validation for Master Card if we have demo these for Visa Card.

Per my experience, a critical system of a commercial bank in Taiwan(I will say the SYSTEM), the are 5 method to change the password of DB account includes:

- Scheduler implemented with Windows service.
- Administrator of Business System
- Administrator of the SYSTEM.
- Highest Administrator of the SYSTEM
- The DBA

The user interfaces of different methods are different. But most of the business logic is the same.
There are about 9 test cases for each method.
So we should have 5*9 = 45 test cases to demo.
If we use T-model filer, we might have 5 + (9-1) = 14 test cases.

The different is between (M*N) and (M+N-1)


Step 2: Prioritizing

There are two options for step 2 to prioritize the features to demo including:

But the features：The attendants buy the features they desired using point or toy coin. This game will more helpful if several business people are invited.

Poster Design: Each attendees designs a marketing poster on a A4 paper, every one design his/her own poster with features desired.

This part is to decide which features are valuable and will delight the attendants during the Sprint Review.


Step 3: Personas and Demo design

Tell stories rather than tell the features.

During the role/personas and stories design, we may need to add/remove/adjust some of the selected features.

Now, we have the most valuable and delighting stories will be shown to the attendants of the Sprint Review.


Wait!!
How about the other features?
During the open discussion session, the attendants may go to individual demo “booth” to touch the real product and detail features. There may be one table for one Scrum Team.

Per my experiences, the PO would be the busiest man during this session. A few attendants would go to the demo booths to discuss the detail feature with developers.

Any input or feedback will be appreciated!