Sprint Review – Make it Much More Than a Demo…

By: Andy Cleff | Aug 15, 2022 |  Agile Technical Practices,  Scrum

In a previous post in our Scrum Assessment Series, we shared some ideas to help catalyze engaging sprint reviews. Here, we take a deeper dive into the topic of awesome Sprint Reviews.

Creating Feedback Loops

The Sprint Review, just like the Retrospective, is an important feedback loop in a Scrum team’s toolbox.

Why is the Review so important? Because it ensures that the team members and their stakeholders are in sync on the priorities, the work being done, and the value being created.

From The Scrum Guide, the purpose of the Sprint Review is to “inspect the increment and adapt the backlog as needed.” 

Let’s Unpack Things

During the Review, the team and their stakeholders discuss what was worked on during the Sprint. Generally steering clear of recaps of technical details, a good review will be a collaborative event, eliciting customer and stakeholder feedback. Some of the work will be potentially shippable, other work will already be live, and some work will not yet be complete (gasp) but in a state where feedback can be obtained.

If the team stops there they will have covered only the inspect aspect of things. And the event is “just a demo.” However, if they keep going, they gain information that can be used to inform the delivery of value via the upcoming Backlog Refinement and Sprint Planning events. That’s the adapt piece.

One of the best ways to make the Sprint Review much more than a demo is to make sure the team tells a good story.

Tell a Good Story

Start by reiterating what the goal of the Sprint was. (The goal was defined during Sprint Planning, and kept forefront during the entire Sprint, right?)  Then during the review, maintain a focus on what’s in it for the customers, stakeholders, or system users.

If the team is using personas, go as far as “bringing the end-user” into the review. Demonstrate a feature using the persona’s name, profession, context, and their concerns.

A successful storyline focuses on value and strategy, elicits feedback, as well lays the groundwork for “what’s next” might look like this:

  • “Here’s what we did and why.” Include one of the following statements:
    • “This benefits our (customers, stakeholders, or system users) in the following ways: ____________________.”
    • “Our (customers, stakeholders, or system users) experience of this will be _____________.”
  • “Here’s how we approached it and the results… showing the functionality from the (customers, stakeholders, or system users) perspective (again, not from the code level…)
  • Trailers for what is “coming soon”…. Acknowledge the plan will be continually reviewed and adjusted…
  • Here’s how we’re tracking on the balance of the Product Backlog items related to this Feature/Epic/Idea.
  • Then an open ended question: “What do you think?” (See “An Example Sprint Review Agenda” below for additional inviting questions.)

Stay away from a dead-end technical-focused Sprint Review and move towards one that breathes life into the event. 

An image of a Scrum team at a Sprint Review ceremony telling the story behind the work they completed during the Sprint.

Guidance for Attendees 

Sprint Reviews are an opportunity for stakeholders to listen and learn from team collaboration regarding Sprint execution. It’s an inclusive space to celebrate wins, provide feedback that helps inform team backlogs, and focus on the storyline, not solutioning. The event informs and orients the group to continuously iterate for the strategic impact of what’s next!

Additional Plot Lines

It is recommended that teams review what they committed to, what they completed, and discuss the delta. What were the challenges the team faced, overcame, etc?

What were some of the key improvements experiments from previous retrospectives that were implemented to help achieve the Sprint Goal or remove some viscosity the team has been dealing with? What future actions are planned? What amount of team capacity would the team like to devote to those activities. The team generally shouldn’t go into great detail here – a mention to highlight continual improvement should suffice.

Full transparency builds trust.

Practice Pragmatism, Not Dogma

There are some common discussions Agile Velocity Coaches have when supporting team leadership roles. Themes and antipatterns we address while helping accelerate the adoption of Agile practices and enabling team ownership include:

  • All stories completed must be demo’d” – To paraphrase Voltaire: The surest way to be boring is to leave nothing out. Focus instead on the stories that have high value to the customer as well as those that the team could benefit from receiving potentially valuable feedback on.
  • Only completed stories can be demo’d” – If an incomplete story is at a point where feedback could be obtained, go for it. Just acknowledge it’s not Done.
  • The Product Owner is seeing the completed stories for the first time – mini waterfall anyone? Product Owner feedback should have already been obtained within the team’s Sprint. 
  • Stakeholder should sign-off at demo” – Ah, danger, Will Robinson. Typically, a team is working thru a number of “small” stories in an Sprint, not one big one… Those stories all have clear a Definition of Done / Acceptance Criteria, and the Product Owner has seen “something” prior to the demo, right? The demo should not be a time of judgment. Any changes that emerge from stakeholder feedback go into the backlog to be prioritized during planning…not holding up the release and learning obtained from putting things into use…
  • The entire team must be at demo” – Daily Stand-ups mean the team knows what’s going on the entire Sprint. While they are all welcome to attend the review event, they all don’t need to be there. That said, ideally, the whole team is there to hear feedback first hand (ear?) and be more informed about their customers’ needs.
  • “Do we have to prepare a great deal of stuff in advance?!” – It’s a good idea to prepare a bit so the review runs smoothly, making sure there are sufficient test accounts and such. The time spent preparing for a demo should be as little as possible. Focus on connecting the dots between the Sprint goals and a cohesive demonstration of the business value created.

An Example Sprint Review Agenda

  1. Team’s Product Owner (PO) opens, acknowledges, and welcomes stakeholders and guests (Warm-up, set the stage, all aligned to the team’s core values… be they serious or playful)
  2. PO presents high-level initiatives/priorities the team is working on, including why these are priorities. (This is both to align the stakeholders and to reinforce the big picture to the team.)
  3. PO or a team member presents the Sprint Goal(s) (and ideally, how they connect to the big picture.)
  4. Team members then present work completed during the sprint, inviting questions, comments, and conversation
    1. Note that this is a feedback loop, not an acceptance meeting. You can completely change the energy of the meeting for good by asking inviting questions like:
      – “What did you expect to see, but don’t?”
      – “What do you love on this page right now?”
      – “What is the first thing that would catch a customer’s eye?”
  5. Optional – PO or team members briefly present stats on non-planned work completed, eg. number of support tickets closed, support turn-around time. (This is to increase system visibility of all the team’s work.)
  6. PO then facilitates a discussion to support the prioritization of upcoming work for the team. This is the most important part of the Review and it is Stakeholder-centric: “Comments on what you saw and your POV of what you think should be next?” (If there’s a pattern that after most Sprint Reviews your backlog is not changed from what it was coming in, you are probably not having impactful Sprint Reviews.)

Wrapping Up

  • Go into the review just as if you were doing a focus group with the end-users (customers, stakeholders, or system users) 
  • Include work-in-progress if it is in a state where you can get feedback.
  • Show the value the team has created during the Sprint.
  • And finally, look forward to refining the team backlog with what everyone has learned from the awesome review!

Comment below if you have any tips on how to encourage others to provide feedback during Sprint Reviews.


If you need help making your Sprint Reviews more successful, our Team Agility Accelerator Service is for you. Contact us for more details about how we can address your specific needs.

Leave a Reply

Your email address will not be published. Required fields are marked *

< Back