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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 |
Below are some tips to help you run engaging and impactful sprint review meetings.
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):
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 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, Product, UX, 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.
In this article, we’ll discuss outcome-driven roadmaps and why they can actually be more efficient and productive than feature-driven ones.
MQ Qureshi talks about his experience with “unexpected sparks of brilliance” — solutions get to the core of what you’re trying to do.
A product review is the moment where you evaluate what the team created over the last development cycle and align on the next steps.
A knowledge base is a centralized location where information is stored in an organized and easy-to-access way.
Learn more →
