The sprint review is part of the scrum framework for product development and management.
Knowing how to run a sprint review is a prerequisite for any product management or ownership role, but it’s important to make the ceremony more than just a demo of work completed during a sprint.
The sprint review should foster team collaboration and evaluate whether progress is being made toward realizing the product vision. Otherwise, the meeting can devolve into rote presentations and your team will miss out on important opportunities to gather feedback.
Table of contents
- What is a sprint review?
- What is the purpose of a sprint review?
- Who participates in a sprint review meeting?
- What happens in a sprint review meeting?
- How often are sprint reviews held?
- How long should a sprint review take?
- What’s the difference between a sprint review and a sprint retrospective?
- Best practices for running a successful sprint review
- Sprint review meeting agenda (example)
What is a sprint review?
The sprint review is a scrum ceremony in which the development team highlights the work it has done during the sprint, demos it for stakeholders, and addresses any questions they may have while inspecting the development.
The Scrum Guide defines a sprint review as an event to “inspect the outcome of the sprint and determine future adaptations.”
The desired outcome of a sprint review is a revised product backlog that defines the probable items for the next sprint. The product owner may also adjust the overall backlog to meet new opportunities
What is the purpose of a sprint review?
A sprint review occurs toward the end of the sprint. It’s an informal meeting between the scrum team and key stakeholders.
In a nutshell, here’s what happens during a sprint review session: The scrum team presents the results of the sprint and all parties collaborate on what should happen next. Next steps may include refining the product backlog to match priorities and conducting a sprint retrospective.
A sprint review is crucial to the overall product development process. Without it, scrum teams may lose out on the chance to assess the product and adapt accordingly. Feedback from key stakeholders is crucial to achieving the goals laid out in the product vision statement.
Who participates in a sprint review meeting?
The sprint review is attended by the scrum team and key stakeholders. All attendees have an active role in running the meeting. For example, the scrum team is responsible for presenting its work and gathering feedback.
Usually, various team members will take charge of certain aspects of the sprint review. Generally, the product owner runs the sprint review meeting and presents what happened during the sprint. Meanwhile, a scrum master facilitates the event.
Stakeholders can include people like end-users, investors, or other teams. The stakeholders will have a chance to interact with the product while also providing feedback. It’s crucial to include stakeholders as part of the sprint process. This makes stakeholders feel involved and more likely to understand the path the product is taking during development.
What happens in a sprint review meeting?
The sprint review is a working session, which means the scrum team should avoid making it a presentation-only meeting. That said, the main purpose of the meeting is to present the results of the sprint and gather feedback from all stakeholders.
Some product owners like to use the sprint review meeting as a way to improve team morale. A review of the work completed is an opportunity to celebrate the team and what it has accomplished. However, the product owner should avoid turning the sprint review into a team-building event.
Generally, a sprint review meeting covers the following activities.
Review goals
The product owner begins the meeting by sharing the product goal and explaining what the scrum team aimed to accomplish during the sprint. This part also covers a review of the original sprint goal and which product backlog items were part of the sprint.
Learn more →Review market changes
To prepare for the sprint review, the product owner should conduct research about current market trends. They may want to present this information during the sprint review so stakeholders can make informed decisions about what should happen next with the product.
Present sprint results
During this part of the meeting, the scrum team presents what it has accomplished and learned during the sprint. This also includes addressing any problems the team faced. It’s important to present problems so stakeholders can understand what issues are occurring and for the scrum team to receive possible solutions.
Demo software
Some product managers make the mistake of turning a sprint review into purely a demo of the product. While the demo is an important part of the sprint review, it’s also essential to let the stakeholders interact with the product directly.
The scrum team may want to set up stations to encourage stakeholder interactions — for example, setting up computers so stakeholders can use new software features. This helps facilitate better feedback on the product.
Collect feedback
Collecting feedback is one of the most valuable aspects of a sprint review. Sometimes, stakeholders don’t provide feedback, but it’s important to create an environment where they can share their thoughts. You’ll want to ask for their feedback throughout the sprint review and make sure participants know their thoughts are welcome.
After demonstrating the product, attendees collaborate on the product backlog and determine what should be prioritized. This discussion informs sprint planning.
Adjust product roadmap
Based on the feedback gathered during the previous stage, the product owner adjusts the product backlog items for the next sprint. This could involve changing the order of items to prioritize others.
The product owner may also discuss the budget, timelines, and capabilities with stakeholders. All of these discussions inform changes that may need to be made to the product roadmap.
Subscribe to our product management newsletter
Get articles like this to your inbox
How often are sprint reviews held?
Sprint reviews are held for every sprint. The frequency of sprint reviews depends on how often your team holds sprints.
Usually, sprints can range from one to four weeks. An organization may have sprint reviews every week, every other week, or monthly.
How long should a sprint review take?
The duration of a sprint review depends on the planned duration of the sprint. Product managers should plan one hour of sprint review for every week of a sprint.
For example, a one-month sprint has a time box of four hours for the sprint review. Shorter sprints have shorter sprint reviews.
However, it isn’t always necessary to take the full recommended time if the product team can gather the necessary feedback and have a robust discussion without maximizing the full time box recommendation.
What’s the difference between a sprint review and a sprint retrospective?
A sprint review is an event that occurs right before the sprint retrospective. While both ceremonies involve reviewing some aspects of the sprint, they have different focuses.
A sprint review meeting focuses on examining the actual work (tickets completed, bugs resolved, etc.) that was completed during the sprint with the aim of updating the backlog. A sprint retrospective, meanwhile, is focused on improving the team’s performance and ways of working together.
Below are some key distinctions between the sprint review and sprint retrospective ceremonies.
| Sprint review | Sprint retrospective |
| Scrum team and stakeholders attend | Only the scrum team attends |
| Goal is to present work to stakeholders and gather feedback | Goal is to improve efficiency for the next sprint session |
| Sprint reviews finish items from the product backlog | Sprint retrospectives create tasks to improve workflow |
| Discusses what the team is working on | Discusses how the team is working |
Best practices for running a successful sprint review
Below are some tips to help you run engaging and impactful sprint review meetings.
- Avoid speaking in jargon. Using simple language ensures all stakeholders understand what happened during the sprint
- Focus on the why. Explain how the items accomplished during the sprint will support customers by removing their pain points and what they will help the customers gain
- Don’t discuss every product backlog item in detail. Not all items are important enough to share, so focus on the highlights
- Gather feedback. Ensure that there is a process to collect feedback from stakeholders. This may include following up with stakeholders after the review to ensure they are satisfied
- Schedule breaks. Sprint review meetings can get lengthy, so it’s important to schedule breaks to let attendees stretch their legs
- Do a rehearsal. Sometimes a rehearsal will reveal flaws in the presentation. This gives you time to fix the issues before the actual sprint review
- Create an agenda. No one likes long meetings. An agenda can help set expectations and keep the sprint review on track
Sprint review meeting agenda (example)
The product owner/product manager should create an agenda before the sprint review. This ensures that all important points are covered and that the review doesn’t go astray.
While every organization will have its own variation, a typical sprint review meeting agenda is broken down into four parts (see an example sprint review meeting agenda below to the right):
- Sprint review — The product owner gives a presentation on the sprint goals and what was and wasn’t accomplished and shares updates about market trends
- Live demo — The development team demonstrates what is new to the product and summarizes successes and challenges it encountered during the sprint. The team may also answer questions from attendees since they are most familiar with the product
- Feedback — Gathering feedback is important during and after the sprint review. This means creating an open and comfortable environment for discussions. The comments should be documented by the product owner for further analysis
- Update backlog — Once the sprint review event is complete, a product owner may make changes to the product backlog or roadmap based on the feedback received
Conclusion
A sprint review is a necessary component of the sprint. If you don’t plan it well, it can turn into a boring event.
When executed thoughtfully, a sprint review can result in valuable feedback from stakeholders, which ultimately leads to a more efficient scrum and products that solve users’ most pressing problems. By celebrating the team’s success, you can boost morale to boot.
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
