How do you (SMs) facilitate Sprint Review?

Here's a blog post that may give some inspiration: https://www.scrum.org/resources/blog/how-facilitate-awesome-sprint-revi…



I have never tried this technique, but I think bazaars are intended when there are multiple teams present. Hopefully in any case, it can inspire you to deviate from what you may conventionally assume a Sprint Review to be.

My advice is to focus primarily on what the desired outcome of a Sprint Review is; specifically as described in the Scrum Guide. 

There are some quick-wins you can do to maximize collaboration, such as:

• Choose an appropriate location
• Set up the room/place appropriately. If there are chairs, don't arrange them so that everyone focuses at one person (e.g. PO), but try for a more circular formation, so that discussion is easier
• Try to avoid or minimize use of tools, such as Powerpoint that place emphasis on everyone listening to a presentation
• Have one or multiple people use the increment as it is being demoed. If it's software, perhaps the demo can be asking a volunteer to try out a new feature on a shared screen, or inviting everyone to demo the feature directly on their mobiles.
• Prepare attendees in advance that their feedback is important, and ask them to give their honest opinions
• If you have anyone in your organization who understands about engaging people (e.g. marketing expert, community manager, customer success, sales), ask them for advice on making the Sprint Review engaging. This is even more useful if this person has attended Sprint Reviews as a stakeholder.
• Ask for stakeholder feedback on the parts of the Sprint Review that were most helpful to them, and whether there is anything they missed from the event.

After the Sprint Review, you can assess whether it achieved its desired outcomes. You can also review the Scrum Guide and see whether your Sprint Review contained all or most of the stated elements.

As a team, you can discuss the Sprint Review at the Sprint Retrospective, and look for ways to improve it.

I've facilitated and experienced different approaches to the Sprint Review. By far the favourite one was the Review we came up with with my first team. This assumes the meeting is in one location, i.e. the Scrum Team and the stakeholders are all in the same room.

We kicked off the Sprint Review by reiterating the Sprint Goal and presenting the PBIs we finished in the Sprint. The development team then gave a quick live demonstration of the features. After that, we turned on some music and split the meeting into two simultaneous parts:

• The PO was at one side of the room with the Product Backlog. The stakeholders could walk up to him and talk about their priorities, the expected release date etc.
• At the other side of the room, the stakeholders had the opportunity to use the software themselves, thus providing valuable feedback to the development team

Stakeholders were walking back and forth between those two part.

Obviously, the tricky part was to synchronise the results, but we were able to do that via a quick standup of the Scrum Team after the Review.

I tend to be a lot less "formal" with my events. I am there to make sure that the event serves the purpose for which it is intended.  Read and understand the Scrum Guide for the purpose each event before you start this.

For Sprint Review:

• I work the the Dev Team and PO prior to the event to ensure that the appropriate stakeholders have been invited
• I get to the room early to make sure that all the tech is working and chairs are available
• I will open reminding everyone the purpose for which everyone is gathered
• I ask who will be "driving" the discussion ensuring that it is either the PO or a Dev Team member that responds
• I make sure that there are no individuals monopolizing the conversation. I will actually cut people off so that others can talk
• I watch the room and the people there looking for body language clues. 
  • Are they interested?
  • Does someone look like they disagree but aren't speaking up?
  • Would it be a good idea to take a short break?
• I ensure that everyone knows how much time is left, keeping the attendees to the expected/planned time box
• I ensure that the PO and Dev Team are capturing the feedback in a way that they can use but I am not the scribe so I am not the one taking notes.

As a Scrum Master, the problem area being addressed/discussed and the technology used is not my concern. My concern is to ensure that the participants are actively engaged, that the event satisfies the purpose and that the time box is honored. 

• I watch the room and the people there looking for body language clues. 
• I ensure that the PO and Dev Team are capturing the feedback in a way that they can use but I am not the scribe so I am not the one taking notes.

I'd like to especially support these two points. Of course, everything Daniel said is helpful. But these two points are very important from the Scrum Master's position, I think.

I agree Simon.