How to run a Sprint Review

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.

looking under the covers

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

Self organising teamsYou 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.

chess10. 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.
11. Record the results
Don’t forget to record the main points of what was agreed.


Remember inspect and adapt.

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


  1. I like the thoughts you present! How do you translate the Sprint review when you are developing software for a client and not just internal use? As a dev shop it seems like we have to put more showmanship into the Sprint Review in order to get excitement and commitment from our clients. Internal scrum teams don’t have to worry about the economics of the client actually saying Stop, as much as dev shops.

  2. Hi Chris,

    Thanks for the comment.

    Firstly, think about the audience for the Sprint Review. I like to ensure we have a good representation of business stakeholders present. It is important that they are present as we are about to inspect progress and adapt our next move. We need their perspective for this to be effective.

    I try to get the product owner to take a lead role. I start out by getting them to talk about the market, what insights they have gleaned about the customers we are developing the product for, any feedback from the customer etc. I like them to create perspective as the team have been buried in product development and the stakeholders busy in their roles. I like a “this is why we are here, this is where we are now and this is where we are going” type discussion.

    We then discuss the latest increment and any observations we have made including challenges we faced, issues we noticed etc.

    Then finally we all collaborate on the product backlog as it currently stands. It is really useful to have a cost per sprint at is point. It allows you to quantify the discussion in money terms. “We are about to spend $92,000 in the next month. What is the most valuable possible thing we could build? Are we sure the product backlog as is stands represents this?” Remember the outcome of the Sprint Review is a potentially reordered product backlog (see the Scrum Guide).

    So for you this will mean getting your client onsite or doing the review at their place. I take it the product owner has been provided by the client?

  3. I agree with the importance of the Product Owner and their role in leading the discussion between the development team and stake holders. We have a PO from our group on every project and help the client identify a corresponding lead.

    I have recently been encouraging the developers to take a more active role in the Sprint Review and to present their work. Our clients have liked this and it generates responses like ” Your team is really excited about this” and ” Jim really knows his stuff, glad to have him on our team”

  4. Edwin,
    This is great – thank you. I too find that the sprint review is the most common meeting that people get wrong. I cringe when I hear people calling them demos for this very reason. When I hear demo that sounds like a “smell” that says, “You must be missing something very important if all you are doing is a demo.”

    The only thoughts I could add to your list are around organizations that aren’t actually delivering the functionality they are developing into production at the end of each sprint but packing it up into a release with a minimum marketable product. I like to coach these teams to look at their release plan and discuss if what they have in mind for the scope and timeline for the release is still on target or if they need to have discussions about adapting based upon current reality.

    I’m going to pass this article on to the scrum masters I coach. So, thank you for providing this resource!

%d bloggers like this: