Learn how to conduct an effective sprint review ceremony to collect stakeholder feedback on sprint outcomes, celebrate team wins, and improve upcoming sprints.
What is a sprint review?
A sprint review is an informal feedback session where agile development teams demonstrate the work they completed at the end of the sprint to stakeholders and product owners. Structured as a collaborative working session, sprint reviews help teams showcase the work done over the curse of the sprint, get feedback on what they created, and confirm that they met their stakeholders’ expectations.
The main attendees of a sprint review should be limited to the scrum or development team, key stakeholders, and the product owner. These attendees may vary depending on the content of the sprint or iteration.
Generally, a sprint review should be an hour long for every week of the sprint, but not exceed four hours total. For a two-week sprint, you should plan on a sprint review taking about two hours.
Sprint review vs. retrospective
A sprint retrospective (or retro) is a Scrum meeting that brings product owners, developers, and scrum masters together to go over what went well, what didn’t go well, and what adjustments should be made following a sprint. It’s meant to be a pulse check on how the team handled the last sprint, and an efficient way to identify what to test in subsequent sprints.
Rather than limiting the discussion to the three main questions of a retrospective (the good, the bad, and the adjustments), a sprint review is meant to include an in-depth discussion of what was completed during the sprint, a demonstration of any new functionality, and a question-and-answer session for all stakeholders.
How to run a sprint review
Follow the seven steps below to streamline your process and run more effective sprint reviews.
1. Conduct a check-in
To kick off a sprint review, it’s important to check in with your team. A check-in can be something as simple as asking, ‘how are you feeling?’ While it may seem counterproductive to use meeting time to check in, in fact, it’s one of the keys to making your meetings more effective, now and in the future. Using a visual platform for your check-ins makes the process easier (and more fun).
Data shows that teams are more likely to be engaged and contribute in meetings that begin with warm-ups or ice breakers, and this has a continuing effect over time (teams become more cohesive — and more connected — as they get to know one another).
2. Review the completed work
The second step in running a sprint review is pretty straightforward: Go through the items that your team completed during the sprint, and then go over what could not be completed or was moved to the backlog for later reprioritization. Be sure to timebox the reviews to ensure your team has enough time to cover all the product increment from the recent sprint.
Again, the best way to do this is with a shared visual platform, so that everyone can see where each item landed, and get an overall sense of performance across the course of the sprint.
3. Evaluate what went well, what didn't, and how you adjusted
Once you’ve painted a clear picture of your product increment, it’s time to look at why the sprint played out the way it did. In a sense, this section of the meeting is like a sprint retrospective included within the larger framework of the sprint review.
Go over what went well, what needs improvement for next time, and what (if any) adjustments you made, or ideas that came up to test in future sprints.
For this section of the meeting, it can be important to make space for independent thought and feedback. You can avoid groupthink by:
4. Go in-depth on what items were completed, demo, and answer questions
Now that you’ve worked through the details and the logistics of what took place in the sprint, it’s time to get more in-depth on what you accomplished and demo any new products or features that were completed.
Next, the Scrum team will demonstrate the tasks they completed during the sprint and cover which tasks were unable to complete. The team members will talk through the new releases, taking time to respond to any questions they may have on a case-by-case basis.
For the Q&A section, it can be useful to provide a framework for comments and suggestions. For example: If you’re launching a new commenting feature, you may want to ask your stakeholders to limit their feedback and suggestions to the UX/UI of the update, rather than the content, as the latter may be addressed by a different team and doesn’t directly pertain to the scope of the project.
5. Discuss backlog and upcoming items
Having completed the demo and recorded any feedback from the question-and-answer session, it’s now time to discuss the sprint backlog.
The product owner should explain what projects are still in the backlog and project delivery dates, including any important details that affect the team’s ability to complete any upcoming tasks. Important details may include capabilities, limitations, budgets, and timelines that the stakeholders should be aware of.
Use the previous discussion as a starting place to talk through how to prioritize the backlog, so that everyone is aligned on what should come next, and what adjustments should be made. Since you have all of the key stakeholders involved, this is an excellent opportunity to get a broad consensus and create clear, actionable next steps.
6. Review any concerns for capacity, budget, or other possible roadblocks
As you build out your next moves, once again take advantage of the opportunity to hear any concerns, be they budget issues or other roadblocks, from all your stakeholders.
The more you can identify up front, before locking in the work for your next sprint, the better. What issues can you anticipate that might prevent your team from completing one or more of your goals? Even things like time of year, personal schedules, or company-wide initiatives that may compete for time are important to consider.
7. Optional energy check & wrap up
In order for everyone to begin anew with confidence, it can be useful to do a quick energy check once your next steps have been identified and outlined.
The Mural Sprint Review Template, included below, builds this into the process and has a suggestion for how to conduct your energy check — but you can modify or adapt this check in to your liking.
Sprint Review Template
Use the below free template to conduct a sprint review session — with an infinite canvas, and pre-built areas to help you organize your ideas and feedback, you’ll hit the ground running and have a single source to reference for your upcoming sprints, as well as to share with any and all stakeholders following your meeting.
As with all Mural templates, you can share it via a link with set viewing and editing permissions, or export part or all of your mural in a variety of formats, so that it can be easily shared or saved anywhere your team tracks documents.
The bottom line
Sprint reviews are an important part of building any feature or product. Sprint reviews are distinct from sprint retrospectives in that they are a more holistic meeting involving an in-depth discussion of what was completed during the sprint, as well as a showcase of any new products or software. They should also include a celebration of team wins, and ample time for discussion to help eliminate or alleviate any roadblocks for upcoming sprints.
The seven steps of a successful sprint review are:
Overview of what items were accomplished during sprint and which were postponed or moved to backlog
Evaluate what went well, what didn't, and how you adjusted
Go in-depth on what items were completed, demo, and answer questions
Discuss the product backlog and upcoming items
Review any concerns for capacity, budget, or other possible roadblocks
Optional energy check & wrap up
Mural is built for better sprint reviews
Mural is the visual work platform for all kinds of teams to do better work together — from anywhere. Get team members aligned faster with templates, prompts, and proven methods that guide them to quickly solve any problem. They can gather their ideas and feedback in one spot to see the big picture of any project and act decisively.
That’s what happens when you change not just where, but how you work.