How to run a successful sprint review meeting

The Scrum framework of project management is based on four basic Agile meetings, i.e., ceremonies: the Sprint Planning meeting, Daily Stand-up, Sprint Review, and Sprint Retrospective.

After each Sprint, it’s important for the team and stakeholders to connect for a Sprint Review to assess the tasks completed. A key component of this review involves demoing the results of the Sprint. But it’s important to understand that the demo is not the sole purpose of the meeting.

Let’s take a look at what it takes to run a truly successful Sprint Review.

Goals of a Sprint Review

For software development teams, there’s a lot of value placed on giving a demo of working software. This practice is widely seen as the main goal of the meeting. In reality, a demo is a component of the goal itself.

More than simply seeing the results first-hand, this meeting is an opportunity for all stakeholders to inspect what was built. This meeting should never lead the audience to act as passive observers. It’s a meeting, which means it’s participatory!

Gathering feedback and insights at every stage of creation is crucial for iteration. Without it, what were once avoidable mistakes start to happen.

Using the feedback acquired during this meeting, the Product Owner (PO) is able to better tailor the product backlog to continuously fulfill everyone’s goals. Successful resource leveling can be the be-all and end-all of a successful outcome. As you can see, the insights and feedback given by stakeholders and the team can be just as crucial as seeing the finished items.

The goal of this meeting is simple: review, assess, and adapt from the previous sprint. In doing both, the team can deliver an exceptional product.

For teams using Agile or Scrum outside of software development, things might look a little different. For example, depending on the field the project is in, a demo might not be the best representation of the work completed. Regardless of how your team presents their work, the goal is the same: review, assess, and adapt.

How to run a Sprint Review

The Sprint Review is comprised of internal and external stakeholders, the team, any other important point persons, and the Product Owner. The PO is responsible for running and managing the review process.

For your meeting, you can use the following outline:

1. Review the Sprint’s results. The PO reviews which items from the product backlog were completed during the previous Sprint and explains any that weren’t.
2. Discuss and demonstrate the work. The team follows up by discussing their successes and pain points during the Sprint. Then they hold a live demo of the finished software (or relay their completed work in whatever medium is appropriate). Finally, the team answers any questions related to the Sprint’s Increment.
3. Update the project status. The PO discusses the current state of the product backlog and restates the project’s scope going forward.
4. Collaborate on the plan ahead. Finally, the team, stakeholders, PO, and any other meeting members work together to finalize the next steps with respect to the insights gained throughout the meeting. For example, your PO may adjust the backlog, or your team may implement new processes for future Sprints. After any changes are agreed upon, it’s important to review all timelines, budgets, and other anticipated events that could affect the project.

The success of a Sprint Review hinges on the productivity of its discussions. Your team discovers nothing about the project ahead without a substantive conversation. Be sure that everyone understands that this meeting greatly determines the quality of your next Sprint.

Tips for a successful Sprint Review

Two things will keep your next Sprint Review moving along smoothly: team unity and effective storytelling.

Team Unity

Some Sprints combine multiple teams to complete the selected product backlog items. This scenario seems like an obvious opportunity for cross-team collaboration. Unfortunately, some fail to fully embrace it.

As you can predict, working separately leads to fractured results. While team members may focus on different functions during a Sprint, the team needs to align on a shared vision. Without this, what team A sees as a top priority might not be what teams B and C see.

Early-stage collaboration keeps everyone’s focus consistent. Many team leaders suggest establishing a theme for the sprint. Essentially, the theme is a string of backlog items that form a logical plot to the end of the sprint. Not only does a theme align everyone in terms of goals, but it also creates a nice illustration of work to be used in the review.

Storytelling

A quality sprint review tells a tale. The quality of that tale depends on how you deliver it.

Product Owners need to communicate more than information; they need to communicate excitement! Your team’s Sprint story can be bland and task-oriented or vivid and immersive. The story of your Sprint should come alive, leaving everyone involved feeling a sense of accomplishment and communal involvement.

Here’s where that theme comes into play: your theme is the building block of your narrative. Using the team’s theme, you have a story written in your mind before the Sprint even begins. Once it’s over, you just need to fill in the details and make any necessary revisions to match what happened. At the end, every backlog item completed should connect in a cohesive, flowing storyline that feeds into the mission of the project overall.

Communicating the story of your work makes it easier for everyone to align their goals and visions for the project and continue to deliver a cohesive product.

Sprint reviews in review

A successful Sprint Review is not about a demo. The demo is only useful to the extent that it provokes thoughtful discussion about what was just built and what needs to be built in the future. Collaboration, not demonstration, should be your main focus in this meeting. Think of your Sprint Review is your team’s chance to regularly inspect and adapt the product the better.

With these guiding points, expect cohesive teamwork that produces the results you desire.

This post was originally published on December 27, 2017, and updated most recently on July 5, 2020.