The most common Scrum meeting that people seem to get wrong is the Sprint Review. I hear people calling it a “demo", a “showcase” or my pet hate the “show and tell". This completely fails to achieve the key purpose of the Sprint Review. Treat a Sprint Review as a presentation and you’ll fail to achieve its key purpose

In our Professional Scrum Master class we work through the follow exercise:

"The team show the Product Owner and other stakeholders the features working. Everyone is really happy with progress. There is a big round of applause and then everyone goes back to work. What is wrong with this situation?"

The answer lies in the three core pillars of Scrum - transparency, inspection and adaption. Every Scrum meeting involves inspecting and adapting. So, if we just do a “demo”, we are inspecting the increment of potentially shipping software. But what are we adapting?

The point of a Sprint Review is to inspect the increment and adapt the Product Backlog. It is a collaborative working session, not a presentation. 

The Sprint Review is designed so that all attendees can inspect what has just been done in the current Sprint and then work together to discuss what the next optimal move is for the business. This means discussing the Product Backlog as it currently stands.

Here is how I run them:

1. Let them know why there’s a Sprint Review
Start by making sure that everyone, including the stakeholders, know the reason for the Sprint Review – that is, it’s a collaborative working session where we will look at working software produced in the last Sprint and then seek perspectives on what we should do next and what might no longer be of value.


2. A team reminder
Remind the team before Sprint Planning that there will be a Review at the end of the Sprint and describe what to expect. They should be able to show:

• an overview of how the Sprint went
• the “done” items as working software
• which items are not done and that they’re now back on the Product Backlog. This is designed to ensure that no hidden work is undone (technical debt) 

We will then, along with other business stakeholders, discuss what we should do next.

3. Ask them how they’ll show their work
At some point throughout the Sprint, ask the team if they’ve considered how they’re going to show their completed work. Maybe they’d like to consider a relevant subset of the acceptance tests to do this? Perhaps each team member might volunteer to do one User Story each? Or one team member could volunteer to show all the user stories working?

4. Visit the stakeholders
In preparation for the meeting, I visit stakeholders and explain why they should attend. We need their perspectives on the next optimal move for the organisation.


5. Help the team prepare
There’s an art to this. Leaders often need to step aside for self-organisation to occur. However, you can often add value as a facilitator so use your coaching skills to ask questions such as:

• What does success of the Review look like?
• What’s the next step?
• How will we know we’ve achieved that?

But remember, you’re not their mother. They selected the work during Sprint Planning, so it’s critical that you step aside and let them take responsibility for the Review. It’s not about you, but about their sense of ownership of the work.


6. Prepare the Product Owner
The Product Owner should understand each User Story well, be clear on the acceptance criteria, able to ask meaningful questions and be ready to discuss the Product Backlog as it currently stands – including what the next highest priority items are. They could also use this meeting as an opportunity to remind the team of the Release Goal. Don't forget – the team have had their heads down in the ‘weeds ‘n all’ Sprint. Remembering the big picture can be immensely valuable.

The Product Owner also plays a critical leadership role by demonstrating the behaviours we all aspire to (after all, behaviours are simply values in action).


7. Watch the clock!
It always amazes me how many companies use a time-boxed framework like Scrum, yet don’t have a wall clock in each meeting room… or even in the building! Make sure there’s a clock in the room!

8. Kick off the meeting

You could open the meeting with a quick check-in round when everyone quickly says how they’re feeling and what’s on their minds. This can help them focus on the Sprint Review and forget what they were thinking about before.
Then, as Scrum Master, remind them of the purpose of the meeting. It might help to outline everyone’s aims for the meeting (along with some behavioural ground rules) on a whiteboard.
Then sit down and shut up! I mean it. Your job now is to ensure that everyone follows the rules of the game, including sticking to the time-frame and facilitating discussion. This is not your meeting, nor are you running it.
Remember, real self-organisation occurs in the absence of management, not because of it. Facilitate goal setting, then let the people doing the work to get on and do it.

9. Stick to the agreed time-box
This can be one of the hardest parts of the Scrum Master role. It is important to hold firm to the time-box to drive out dysfunction. Remember the definition of insanity – "doing the same things and expecting different results". If you don't hold the meeting to time, it will likely run over next time and the time after that.

10. Make time to discuss the next move
The Product Owner should be able to discuss the Product Backlog as it currently stands and then invite open discussions about whether this is what we should be doing next. Is there a more optimal way? If so, how would we measure this? How would we know? Ultimately, the Product Owner has the final call, but anyone with a vested interest in the project should be present as this is a great opportunity for discussion

Remember inspect and adapt..

Is this how you run your Sprint Reviews? What are your experiences?