Conducting an interesting and engaging end-of-sprint review is an often overlooked art: Not only do we want to show what we have built during the last sprint and collect feedback and good ideas for what to build next; we also want to give our audience a good experience.

At my workplace we always invite the entire company and often have more than 30 people in the room. As they claim to be happy and to enjoy the fortnightly experience I thought it might be useful to share our template and some guidelines for what is working for us.

Our cheat sheet

General guidelines

• The point is not to show that your software works but that it is useful and valuable


• Provide context and scenarios so that people can relate to features (role plays work great!)


• Don’t forget there is an element of show and entertainment. If people give up time every 2 weeks to come to your demo make it a good experience for them.


• No smoke and mirrors and never ever show anything that is not 100% done (see acceptance criteria and the definition of done)

Our sprint review agenda

This is our usual flow through the review:

1. The Scrum Master opens the review and reiterates the purpose

• Show what the team has built during the last sprint


• Engage with the audience


• Collect feedback

2. The Product Owner presents what he wanted to get out of the sprint

• Describe the sprint goal and why you chose it


• Explain why it is important for the project and for the company as a whole


• Give people context about where we’re at in the greater scale of things

3. The Scrum Master presents the sprint

• Tell the story of the sprint: How did it go? Did you have level 3 support incidents? (We handle those in a support work time box) Was anyone sick? New team members? Anything else important?


• Give a status of the sprint and an overview of which stories were finished and which ones weren't

Green check means “done”, red cross means not 100% done and therefore won’t be demoed.

4. For each story:

• The demoing team member shows the story description and describes the boundaries (explain the acceptance criteria without reading them out)

The story we are about to demonstrate

• Demonstrate the feature on a real system, in this case generate the report and show the result.


• Take questions and listen to feedback while you demonstrate. Remember to collect ideas for new features and user stories to include on the product backlog.

• Repeat step 4 for all user stories the team finished during the sprint.

On some teams we alternate who is doing the practical demonstrations for each user story, on some we alternate for or each sprint review and on others we always utilise the same team member’s talent for telling stories and guiding people through an entertaining demo. We do whatever works best for each team and audience.

5. Scrum Master closes the demo

• Wrap up and thank people for their attendance and participation


• Communicate the time and date for the next end-of-sprint review.

Some general Tips

Here are some things we have learned during the process of continuously improving our sprint reviews:

• Audience participation and interaction works really well: If possible we ask audience members to play roles in our scenarios such as e.g. a customer who has lost his Snapper card.


• It is really important to prepare. We found out the hard way that it is a good idea to trial the demo before giving it to a larger audience to make sure it flows and that all the accounts, logins and data are set up.


• It is good practice to have the agenda visible on a wall or whiteboard at all times. This serves as a map of the territory we have covered last sprint. It is especially useful if some people come and go during the demonstration (our customer facing folks often do)

In summary, the most important thing to make sure everyone enjoys the sprint review is to focus on demonstrating the value and usefulness of the features we have built and to make sure people can relate to the software by providing context and scenarios.

Where to from here?

As more and more teams within Snapper are using various Agile or Lean approaches and would like to show what they have done since their last demo we are planning to hold bi-monthly combined show and tells.

The plan is that the product development team will demonstrate all features they have finished during the last two weeks and then the marketing team, our latest Scrum addition, will present what they have achieved during their sprint. Ideally, the marketing deliverables will match the product development team’s features.

We will then round up with the operations team who have chosen Kanban as their preferred approach. The ops team will show any major deliverables and will present key metrics such as cycle time, lead time, throughput etc.

The challenge will be to keep the show and tell under an hour and I hope we can keep people engaged, informed and entertained.