As Agile teams wrap up the sprint, they hold a sprint review—seen by many as the best day of the sprint! 

While sprint reviews can initially bring about nerves for presenters, when done well, they become exciting, energized meetings that connect teams across the organization. 

Here’s what you need to know about sprint reviews and how to make your next one as successful as possible. 

The sprint review is one of the five Scrum events, and it’s a time for the Scrum team to present the work they’ve done during the sprint. The sprint review should address the question, “How did we do on the sprint goal?” 

Typically, the developers demo their work to stakeholders and other meeting attendees, talk about the ups and downs of the sprint, and ask for feedback. The learnings from the sprint review inform the next sprint and could shift the product direction. 

The purpose of a sprint review (or iteration review) is to inspect the outcome of the work, present results to stakeholders, and gather feedback to inform future planning. The meeting serves as the connection between development and business teams. The Scrum team has a chance to better understand the requests being made by business teams, and business teams see what’s feasible to request and what’s not.

The sprint review is held on the last day of a sprint before the sprint retrospective so that learnings from the sprint review can be brought to the retrospective. 

The Scrum team—the product owner, Scrum master, and developers—along with stakeholders, should attend the sprint review, but the meeting is pretty open to anyone else who wants to attend as long as they support the meeting’s purpose. Other attendees could include executives, managers, other Scrum teams, and even customers. The sprint review can be a small or large meeting depending on the organization.

The Scrum master should facilitate the meeting, the product owner should welcome the stakeholders and briefly talk about the product roadmap, developers should spend the majority of the time presenting, and then stakeholders will have time to give their input.

The sprint review agenda includes:

• Welcoming the group and providing an overview of the sprint goal and target outcomes.
• Showcasing completed work accomplished during the sprint.
• Gathering stakeholder feedback about the demonstrated work, including appreciations, concerns, and suggestions.
• Discussing progress toward the product goal and reviewing any changes in environmental factors.
• Closing the meeting.

Sprint review agenda example

Closing the meeting should include looking toward the future for a few minutes and showing appreciation. While you don’t want to dive too deep into the product roadmap, the product owner could give just a quick glimpse of what’s to come in future sprints. As for appreciation, facilitators can use a virtual whiteboard like Lucidspark where the team can leave shout-outs for team members’ contributions.  

According to the Scrum Guide, for a one-month sprint, the sprint review timebox should be four hours. Shorter sprints generally have a shorter sprint review meeting. 

When deciding how long to make your own sprint review, consider whether stakeholders will be in attendance and, if so, how long they can stay. Often, limitations on stakeholder time lead to the sprint review lasting about one hour. 

Keep in mind, you can continue to reconfigure your sprint review meeting to fit the needs of your team and stakeholders.

Some topics that may be discussed during the sprint review include:

• The sprint backlog and sprint goal.
• How the work presented fulfills the acceptance criteria of a backlog item. 
• Before and after metrics that concretely demonstrate tangible progress.
• Challenges during the sprint that the team learned from.
• Stakeholder feedback.
• How the work presented collectively affects functionality, UX, or business value.
• Some high-level, collaborative planning about next steps.
• A brief discussion of adjustments needed in the product backlog to incorporate feedback and meet new opportunities.
• Appreciations.

Topics that should not be discussed include:

• Internal team dynamics (save for the sprint retrospective).
• Blame for low performance.
• Detailed technical discussion such as questioning the team’s technical implementation.
• Expanding too much on the roadmap rather than keeping to what was in the sprint.

The sprint is all about collective work, so the sprint review should focus on “we,” not “I.” 

Good facilitation will set up your sprint reviews for success and help engage both the Scrum team presenting and the participants in attendance. We rounded up sprint review tips from experienced Agile coaches Bryan Stallings and Jessica Guistolise for your next sprint review meeting to go as smoothly as possible! 

Be prepared

Preparation is the key to an effective sprint review—for both facilitators and participants. 

Team members should test what they’re going to show during the meeting so that they’re not showing something broken. If a developer isn’t going to show the work itself, they may visually display some data points or benefits or instead show the impact of not doing the work. Visual collaboration software like Lucid makes sharing visuals easy without presenters having to put in a ton of time. 

Facilitators should make sure artifacts and metrics are ready and that the right stakeholders have been invited to the meeting with enough notice. Just be sure to not overprepare—there’s no need to create slide decks for sprint reviews. 

Using a sprint review template like the one below can help you set the agenda and prepare for your meeting ahead of time.

Sprint review template (click to use template)

Bonus tip: To get more executives to the sprint review, put upcoming sprint reviews on their calendars well in advance and hold the meeting at a consistent time. Eventually, more executives will be able to attend and see the value of the meeting.

Assist the team in showcasing their work

Sometimes team members are unsure of how to show their work. For example, if a developer spent the sprint cleaning up a database, they may not want to show just the database. This is where facilitators can encourage team members to think about why they did the work. Did page load times improve because of cleaning up the database? Again, they may also consider showing the impact of not doing the work.

Make the agenda visible

The sprint review agenda should be visible from the start of the meeting so that stakeholders know what the plan is and so that the meeting starts and ends on time. Punctuality encourages stakeholders to attend the meeting in the future. 

Creating an agenda that’s accessible to everyone is easy with Lucidspark. Start from scratch and share your agenda on a meeting board, or use a template to get a head start. 

Balance the demo with discussion

Working software is important, but it’s also helpful to talk about what happened during the sprint, including what the team accomplished, what the team didn’t accomplish, and the impact of decisions made throughout the sprint. If you already have your sprint board in a virtual whiteboard like Lucidspark, you can use those visuals to help explain what the team did and did not accomplish.

Example of a sprint board in Lucidspark

Foster constructive feedback

Sprint review meetings include a lot of feedback. Often developers show partially completed functionality, and sometimes stakeholders–whether executives or customers–realize that functionality is not what’s needed. The stakeholders may also share feedback about the market or the business. This feedback ultimately leads to an improved product backlog and important shifts for the next sprint. 

It’s best if the Scrum team can thank stakeholders for their feedback and recognize that it isn’t personal. That being said, sometimes the facilitator will have to educate the audience on how to participate in a sprint review. While the sprint review is a time for feedback, it’s not the time for managers and executives to derail the meeting or take over the discussion.

The facilitator can help educate the audience by explaining the purpose and format of a sprint review as the meeting opens. They can also describe the role of each participant and explain what happens at each phase of the agenda. A facilitator can set expectations for engagement and interaction, how participants engage at each step of the meeting, and intervene as needed. For example, a facilitator may provide guidance on how to give constructive feedback. Effective facilitation ensures all attendees can contribute effectively, leading to more productive sprint reviews.

Make room for celebration

Larger sprint reviews, especially those that include multiple Scrum teams, can be really exciting! Seeing the work and progress is powerful for a lot of different teams even outside of product development, and the energy often grows the more product backlog items are presented. 

Feedback is important and so is taking the time to celebrate the work that’s been done and what the team has learned. Remember, learning what doesn’t work is also progress.

Some ways you can celebrate include:

• Highlighting achievements as developers showcase completed work and milestones reached.
• Using visuals like charts and graphs that illustrate progress over time.
• Including an agenda item to hear from stakeholders about appreciation for the team’s work.
• Creating a celebratory atmosphere with small gestures like snacks or visuals to mark the event (this even works virtually).
• Planning for team members to briefly discuss challenges overcome or innovative solutions found.
• Showing how sprint accomplishments link to larger goals and contribute to broader project or organizational objectives.
• Recognizing team efforts by acknowledging individual and collective contributions.
• Concluding the review on a high note by summarizing key successes and expressing optimism for future sprints.

Depending on the team culture, if the sprint review is held in person, people may even clap or use noise makers. Virtually, teams can use emojis in real time to celebrate across apps like Lucid and Zoom.

Focus on continuous improvement

After the sprint review is wrapped up, facilitators should focus on continuous improvement for future meetings. They should think about how to get more attendees and encourage more participation, and they may bring up discussion around those goals in the sprint retrospective.

While both events are held at the end of the sprint, the difference between the sprint review and sprint retrospective is that the sprint review is the public end of the sprint, and the retrospective is the private end of the sprint. 

The sprint review is open to anyone. The sprint retrospective is only open to the Scrum team and those they ask to be in attendance because the retrospective covers more internal, sensitive topics like team dynamics and conflict. The sprint review should focus on what happened in the sprint as far as the backlog items go, but the retrospective should focus on how the team’s collaboration and working relationships are going.

Hold effective and engaging Agile events with Lucid—whether you work in person, hybrid, or remote. With features built for facilitation and real-time collaboration, Lucid can help you adapt Agile to your modern workplace.