The sprint review is a meeting of an agile development team including Scrum Master and Product Owner, stakeholders, customers, business, and line management to present the status of the sprint and compare it to the commitment given at the beginning of the sprint.

In Scrum, the sprint review is a session that closes a sprint (10-15 days iteration) in which completed functionality is demonstrated to the client’s representatives. Such a review is also called Sprint Demo. Agile coaches suggest providing that information in a live demonstration showing completed functionality.

For the business, this is different compared to the previous, waterfall-like process. They see the results very often and regularly, which helps to constantly adopt the product according to changes on the market.

How to make sprint review interesting?

Sprint review meeting goal

The goal of the sprint review meeting is to share information with customers about work transparently:

• has been done,
• has not been done,
• work that has been added,
• and work removed from the sprint.

As Agile is based on transparency and feedback, customers (or business representatives) are asked to provide feedback on the team’s results. The big advantage is a personal meeting of the team and customers/business representatives.

Sprint review topics

• When did the sprint begin and finish?
• Who worked on the results?
• What was the goal of the sprint?
• What has been planned?
• What was done and what not?
• What has been added and what removed from the sprint?
• What risks and problems were discovered?
• Demonstration of developed functionality.
• Feedback from participants.
• Information about the next sprint.

Sprint review responsibilities

Product Owner

• An introduction to sprint goals.
• An introduction of planned top requirements that the team has committed to deliver.
• Sprint status overview
• Information about defects and improvements solved during the sprint improving quality.

ScrumMaster

• An organization of the meeting, an invitation to participants.
• Moderator of the meeting
• Evidence of feedback.

Development Team

• Informs about the sprint status.
• Live demonstration of functionality.

Sprint Review Agenda

The sprint review meeting should not be very long, 45 minutes + 15 minutes for discussion. It should have its flow and energy. Make it energized, valuable and stakeholders will return for the next sprint review.

Every part of the meeting is ideally provided by a different role. All roles (agile development team, Scrum Master, and Product Owner) are included in the presentation of sprint results. This way, your Sprint review meeting will be entertaining and not just another boring demo session.

Following is an example of the invitation to the Sprint Review meeting sent by Scrum Master to stakeholders of the agile team. Adapt time slots to your needs, but not make them too long. People lose concentration after 45 minutes. Therefore, take appropriate breaks if you need to do a more extended sprint review.

Sprint review agenda

How to prepare for a great sprint review

Start the preparation before the sprint planning session. Before planning, the Product Owner should imagine a sprint review session, especially the opening.

Which 3 goals you want to aim in the sprint for?

Multiple backlog items will fulfill these three goals. The most important can be recognized upfront so the product owner can guide team members on which user stories will be necessary to demonstrate at the sprint review session. Much easier for them to prepare for the demo.

Always talk in business language. We found a very usable, simple principle.

There should be no technical term in sprint review.

Try to communicate why you developed something, what kind of pain you removed, which job, and whose job is simplified. Communicate in a language that the audience understands; they can directly imagine an impact on their life.

Keep it short and simple. Guy Kawasaki, a great speaker, and entrepreneur defines excellent presentation with the 10-20-30 principle. 10 slides, 20 minutes, 30 points font.

Well, in the demo, you maybe do not need to have a presentation (btw, it helps a lot from real life), but 10-20-30 is applicable even in the demo:

• Maximum 10 screens + pictures+ videos + slides at all.  Less is always more!
• Maximum 20 minutes. Save additional time for questions, answers, the feedback. For reasons why sprint review is held. Less is always more.
• No small letters, no barely readable texts. Smaller is not always more :).

For sprint demo prepare: 

1. Prefill data in the application forms you will be presenting.
2. Prepare screens for edge cases if you need to show them.
3. If something takes more steps, record a video and speed it up.
4. Show time-lapse.
5. Connect to all necessary services, shared folders, etc. Who wants to attend yet another demo where you see login name admin with password *******?
6. If you show performance improvements, compare them with the previous version. We want to hear gains. Don’t provide just %. Talk to us in milliseconds, a load of x thousands of users, etc.
7. Comment burn down and velocity charts with comment bubbles so stakeholders can read them later if needed.
8. Put only title, not whole explanation of problems. Talk about details, but do not write it because you need to use 6pt fonts.
9. Know who to invite and mark as mandatory in the invitation. The outcome might not be interesting to everybody. But do not exclude people from the review. If they want to attend, if it is their willingness to invest their life into your session. Welcome them!
10. Do rehearsal. Do not be ashamed. Great speakers are doing them as well. Keep training in front of your team colleagues. Ask for their feedback.

Five tips on how to demonstrate

1. Describe the problem, pains, jobs, or gains.
2. Mention who is a persona doing that job, having the pain.
3. Explain what is expected as the correct result.
4. Demonstrate the functionality. Simply, straightforward, without technology words.
5. Ask for feedback.

Keep the timing according to the agenda. Scrum Master is responsible for the schedule and moderates the sprint review.

The Product Owner is the leader of the meeting. She represents the team, the head of the development body.

Development team members demonstrate functionality.

All team members participate to some extent in the sprint review session.

Product owner+scrum master + team.

We saw how more than a hundred Scrum Masters prepare for the sprint review session. We were keen to understand what kind of information they have to provide to the stakeholders. What we saw were dozens of minutes spent on the preparation itself. We are pretty sure that for such Scrum Master this is not a way to live a life.

We built the sprint review document into the tool from which it can be saved to PDF and sent to stakeholders.
All done in one minute, you do not need to work on the presentation for an hour.

With ScrumDesk you can prepare far faster and sooner for the sprint review:

1. Product owners can manage agile roadmaps to focus on the right things in mid- and long-term.
2. Every sprint can have defined the purpose of the sprint in form of sprint goals defined by the Product Owner.
3. The Product Owner can mark user stories that should be demonstrated with help of color, or tags, or flags.
4. The sprint review document contains everything you need for a real agile sprint review session. Its design is based on dozens of agile teams’ presentations and sessions we attend.
5. Based on the feedback of Scrum Masters, it saves an hour of Scrum Master in the preparation of an overview at the end of the sprint.
6. Screenshots, movies, time-lapse can be attached to the user story directly. Have one repository for all assets.
7. Comments can be provided directly to user stories even by guests. We offer free guest licenses for your stakeholders.

10 typical sprint review mistakes

1. Detailed status of every sprint backlog item.
2. Discussion about hours. Remember, in Agile you deliver value, you do not spend time.
3. Discussion about capacities.
4. The demonstration is not prepared, you click and explain every aspect of the presented functionality.
5. The presentation, if prepared, is full of bullets and details. Just in case some people do not attend the review.
6. Feedback is not gathered. Use Feedback/Happiness door technique at least.
7. The timing is not managed.
8. Only the Product Owner speaks in the sprint review.
9. The sprint review is done for the Product Owner.
10. No sprint review.