How to run a successful sprint review meeting

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

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 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.

Logistics

The Sprint Review is comprised of internal and external stakeholders, the team, any other important point person’s, 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 answer any questions related to the Sprint’s Increment.
3. Update the status of the project. The PO discusses the current state of the product backlog and restates the scope of the project going forward.
4. Collaborate on the plan ahead. Finally, the team, stakeholders, PO, and any other meeting members work together to finalize next steps with respect to the insights gained throughout the meeting. For example, your PO may adjust the backlog or your team may impliment new processes for future Sprints. After any changes are agreed upon, its 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 success

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 could 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, 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.

It’s important for PO’s to do more than communicate information; they need to communicate excitement! Your team’s Sprint story can be bland and task-oriented, or it can be 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 blocks 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.

In conclusion

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.