The sprint review is a meeting of an agile team with a Product Owner, 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. Very often such a review is called Sprint Demo because it is suggested to provide that information in form of a live demonstration showing completed functionality.
For the business, this is definitely different comparing to the previous, waterfall-like process. They see the results very often and regularly, which helps to adopt the product according to changes on the market constantly.
The goals of the meeting
The goal is to transparently inform the customer about work which:
- has been done,
- has not been done,
- work that has been added,
- and work removed from the sprint.
Also, customers or business representant are asked to provide feedback on the team’s results. The big advantage is a personal meeting of team and customers/business representatives.
What to talk about in sprint review?
- When the sprint began and finished?
- 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.
Who and what (Activities)
- 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.
- An organization of the meeting, an invitation to participants.
- Moderator of the meeting
- Evidence of feedback.
- Informing about the sprint status.
- Live demonstration of functionality
Sprint review agenda
How to prepare for a good sprint review?
Start before the sprint planning session. Yes, you read that correctly. Before the planning, the Product Owner should imagine a sprint review session and especially the opening.
Which 3 goals you want to aim in the sprint for?
These three goals will be fulfilled by multiple backlog items. The most important can be recognized upfront so the product owner can even 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 remove, 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 great 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, for 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 :).
In all cases prepare for the sprint demo part:
- Prefill data in the form.
- Prepare screens for edge cases if you need to show them.
- If something takes more steps, record a video and speed it up.
- Show time-lapse.
- Connect to all necessary services, shared folders, etc. Who wants to attend yet another demo where you see login name admin with password *******?
- 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.
- Comment charts with bubbles so we can read them later. If necessary.
- Put only title, not whole explanation of problems. Talk about details, but do not write it because you will need to use 6pt fonts.
- 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!
- 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 the functionality
- Describe the problem, pain or job, or gain.
- Mention who is a persona doing that job, having the pain.
- Explain what is expected as the correct result.
- Demonstrate the functionality. Simply, straightforward, without technology words.
- Ask for feedback.
Keep the timing according to the agenda. ScrumMaster is responsible for that. ScrumMaster moderates the sprint review. The Product Owner is the leader of the meeting. She represents the team, the head of the development body. Team members demonstrate functionality.
All team members participate to some extent in the sprint review session.
Product owner+scrum master + team.
- Detailed status of every sprint backlog item.
- Discussion about hours. Remember, in Agile you deliver value, you do not spend time.
- Discussion about capacities.
- The demonstration is not prepared, you click and explain every aspect of the presented functionality.
- The presentation, if prepared, is full of bullets and details. Just in case some people do not attend the review.
- Feedback is not gathered. Use Feedback/Happiness door technique at least.
- The timing is not managed.
- Only the product owner talks in the sprint review.
- The sprint review is done for the product owner.
- No sprint review.
How ScrumDesk supports sprint reviews?
Our vision is to provide the tool for Scrum teams that saves time and energy with boring stuff. We saw how more than a hundred of ScrumMasters 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 those ScrumMasters this is not a way to live a life.
Therefore, we built the sprint review document directly into the tool from which it can be printed, saved to PDF and then sent to stakehodlers. All done in one minute, you do not need to work on the presentation for an hour.
With ScrumDesk you can, however, prepare far sooner before the sprint review for the sprint review.
- Product owners can manage agile roadmaps to focus on the right things in mid- and long-term.
- Every sprint can have goals defined by the product owner.
- The product owner can mark user stories that should be demonstrated with help of color, or tags, or flags.
- 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. Based on the feedback of ScrumMasters it saves an hour of ScrumMaster in the preparation of an overview at the end of the sprint.
- Screenshots, movies, time-lapse can be attached to the user story directly. Have one repository for all assets.
- Comments can be provided directly to user stories even by guests. We offer free guest licenses for your stakeholders.