Sprint reviews: how to hold effective review meetings

Sprint Reviews are one meeting your team shouldn’t skip – they’re a part of Scrum for a reason!

When run correctly, Sprint Reviews will level up your team and make your next Sprint that much better. If your Sprint Reviews are feeling stale, or you aren’t holding them, we have some tips for how to improve.

What is a sprint review?

In short, it’s a meeting for the following people to get together for a demo, or show-and-tell, at the end of a Sprint.

The Scrum framework calls for the completion of a shippable product increment during each sprint. Therefore, you should be able to demonstrate a fully-functional feature, or set of features, at the end of each Sprint. So, think of this meeting as a celebration of that accomplishment.

Scrum sprint review meetings are held every sprint before the retrospective meeting which marks the very end of the sprint.

Who attends a Sprint Review session?

• The Product Owner
• A Scrum Master
• Developers
• And any Other stakeholders (including management and sometimes the end-users).

How often are sprint reviews conducted or held?

Sprint reviews are held at the end of each sprint, so their frequency is dependent on the length of the team’s sprints. For most agile teams, the average sprint is between 2-4 weeks, so expect a sprint review to happen 1-2 times per month.

What is the purpose of a sprint review?

The purpose of this meeting is to answer a simple question:

Did the team meet the goal assigned at the beginning of the sprint?

To be clear, even if the answer’s a resounding no, the Sprint Review should still recognize the team for the work that was completed. Everyone should actively participate in the Sprint Review by offering questions, comments, or concerns (nicely!) on the work done.

Other benefits of sprint review meetings include:

• Improving the quality of the final deliverables
• Keeping stakeholders engaged by requesting and making use of their feedback
• Helping your team maintain collaboration best practices
• Maintaining project transparency
• Updating the sprint backlog and reprioritizing (if needed) the story points
• Motivating your team and showing appreciation

This review meeting helps shape future sprints. For example, based on what the developers show, the team may need to make changes to the product backlog before the next sprint. Whether this happens is based on criteria like:

• Whether the team met the initial goals set during the sprint planning meeting
• What insights are provided by those present during the Sprint Review

If your Sprint Reviews are starting to feel stale one reason might be you’ve slipped into only focusing on showing completed work. Don’t forget to make these meetings interactive so that each member of the team can offer their perspective on the completed work. This is a great opportunity for an open discussion.

Holding an effective sprint review meeting

Now that we’ve established the purpose of a Sprint Review, how should you run yours?

How do you ensure your team gets the most value out of their time? How do you foster a collaborative environment where people feel free to share their thoughts without fear?

Read on for some of our favorite tips on how to structure and run your Sprint Reviews.

Keep the sprint review meeting short to stay the course

So how long is the Sprint Review meeting?

A better question to ask the team is: How short can you make your Sprint Review without sacrificing quality?

The average Sprint Review meeting length is no more than two hours for a two-week Sprint, but can yours be even shorter? While the maximum Sprint Review meeting timebox is four hours, some groups have reduced the amount of time spent on Sprint Reviews from two hours to an hour.

Limit what’s covered in these meetings to keep it short.

Remember, a Sprint Review isn’t the same thing as a Sprint Retrospective. The Sprint Review is a time to celebrate the progress your team has made. Save the conversation about what they should or should not be doing for the Sprint Retrospective. By keeping the two separate, you’ll save time and preserve the effectiveness of both aspects of the Scrum process.

If you still find yourself sitting in Sprint Reviews (or any other meetings for that matter) that are way too long, consider timeboxing.

Timeboxing is the process of scheduling out exactly how much time should be spent on each task (e.g., 5 minutes for introductions, 10 minutes for a demo of the first item, etc.). You’ll need to nominate someone on the team to enforce such limits during the meeting.

Set an agenda

Sprint reviews are informal, but they needn’t be anarchy. So what do you do?

Setting a sprint review meeting agenda, however loose, will help set your team’s expectations and keep you on track. For instance, you might stick to a simple four-part Sprint Review:

1. Review the results of the sprint: the product owner covers which items of the backlog were completed during the sprint (as well as any that weren’t and why)
2. Demonstrate the work: the dev team demos their work and talks about the successes and challenges encountered during the sprint
3. Gather feedback: during and after the demo, the entire Scrum team should feel free to offer feedback about the completed work. The product owner should ensure this information is well documented.
4. Update the project and plan for future work: based on the demo and the feedback received, the product owner should lead the group in updating the backlog to reflect changes in scope, newly discovered work, shifts in priorities, and unfinished pieces of work in order to prepare for future sprints.

There’s no one size fits all when it comes to Sprint Reviews. Your team will have to decide what works best for them. Only by trial-and-error can you determine the right structure for your team.

Avoid judgment

There’s a fine line between constructive feedback and critical judgment. It’s crucial that the Sprint Review maintains a positive spirit. The team shouldn’t feel as if the agile Sprint Review is an opportunity for the product owner and other stakeholders to “grade” or judge the work they have completed.

One way to prevent this is to include the product owner as an active participant during the demo.

How does this help?

When the person who sets the direction of the feature work actively participates they become “one of us” instead of “one of them.” There’s likely to be a trickle-down effect where everyone works together and when something needs to be addressed, it’s likely to be done in a collaborative, fair, and useful manner.

Sprint review meeting conclusions

Sprint reviews are a vital component of the Scrum process, but they can easily become stale and less effective.

Don’t let this happen. With the tips provided above, you can make sure that your team’s Sprint Reviews stay productive and effective. Sprint review meetings are a great way to gather feedback informally, but more importantly, it’s a bi-weekly celebration of what your team has accomplished. What could be better?