Over the years, I've been asked multiple times what a Nexus Sprint Review might look like. I've not been satisfied with the guidance I've found online regarding Nexus Sprint Review, so I decided to finally write my own." Please feel free to adopt any ideas from this post and run your own experiments. Also, if you are not using the Nexus Scaled Scrum Framework, that's fine. Just know that in this blog post, when I refer to Nexus Sprint Review, you can think scaled Sprint Review.
What does the Nexus Guide state?
The Nexus Sprint Review is held at the end of the Sprint to provide feedback on the Done Integrated Increment that the Nexus has built over the Sprint and determine future adaptations. Since the entire Integrated Increment is the focus for capturing feedback from stakeholders, a Nexus Sprint Review replaces individual Scrum Team Sprint Reviews. During the event, the Nexus (representatives) present the results of their work to key stakeholders, and progress toward the Product Goal is discussed - although it may not be possible to show all completed work in detail. Based on this information, attendees collaborate on what the Nexus should do to address the feedback. The Product Backlog may be adjusted to reflect these discussions.
What about the individual Scrum Team Sprint Reviews?
Since the Nexus Sprint Review replaces the individual Scrum Team Sprint Reviews, everyone (all Scrum Team members) participates. Rather than inspect the various Scrum Team outputs, stakeholders are inspecting the Integrated Increment. Just like in a single team Sprint Review, any stakeholders who can collaborate and provide value (in the form of constructive feedback) should attend and participate.
Because you will have a large audience, with short attention spans, you may need to employ a complementary practice to increase transparency and feedback. Traditional “stand and deliver a demo” typically doesn't work, even for single-team Scrum.
Sprint Review Bazaar
A popular complementary practice for a Nexus Sprint Review is to diverge and converge (or diverge-merge). The diverge-converge approach begins by having stakeholders diverge (go to breakout rooms) to inspect specific aspects of the product to provide more targeted feedback. This allows stakeholders to only inspect aspects of the product that they are interested in. Following this, the stakeholders can converge back together to summarize their opinions and feedback from the various rooms. Scrum Teams practicing this will often use a bazaar, which is analogous to a science fair or a car show, with a large room (physical or virtual) with multiple areas/rooms/shops, each staffed by Scrum Team members. Attendees inspect and discuss the items developed by each team. There may be multiple diverge-converge cycles. The bazaar can also remain open for the duration of the Nexus Sprint Review.
Sample 2.5-hour Nexus Sprint Review agenda (diverge-converge bazaar)
- 9:00 am - Stakeholders are welcomed and reminded of the purpose, expectations, agenda, and logistics of the Nexus Sprint Review; the Product Vision, Product Goal, and Nexus Sprint Goal are shared; Market/business conditions are discussed as well as any experiments and related learnings
- 9:10 am - Attendees are informed of the high-level capabilities and features that are Done and can be inspected; this is a pitch to attend a specific room to inspect this aspect of the product
- 9:20 am - Inspection round 1 (diverge) Attendees visit a room, inspect that aspect of the product, and provide feedback; Team members collect any feedback
- 9:40 am - (merge) A representative from each room shares a summary of the feedback and learnings based on their inspections; Team members collect/refine any feedback and update the Product Backlog as appropriate
- 10:00 am - Break
- 10:10 am - Inspection round 2 (diverge); Attendees visit a different room, inspect that aspect of the product, and provide feedback; Team members collect any feedback
- 10:30 am - (merge) A representative from each room shares a summary of the feedback and learnings based on their inspections; Team members collect/refine any feedback and update the Product Backlog as appropriate
- 10:50 am - All feedback is grouped, clustered, and made transparent; stakeholders share any insights and market developments, a new Product Goal is considered; stakeholders are made aware of any upcoming Product Backlog Refinement sessions
- 11:20 am - A short retrospective of the Sprint Review, so that stakeholders and anyone else who can't make the Nexus Sprint Retrospective can still provide input and suggest improvements
Just as with a single-team Sprint Review, informal discussions can continue as needed.
Give it a try, and let me know how it works for you and your teams, but remember plans, such as the above agenda, will probably fall apart during execution. Be ready for that.