What is done during a sprint review meeting

The sprint review is an informal meeting which the development team, the scrum master, the product owner and the stakeholders will attend. The team gives a demo on the product and will determine what are finished and what aren’t. The purpose of the Sprint Review meeting is for the team to show the customers and stakeholders the work they have accomplished over the sprint and compare it to the commitment given at the beginning of the sprint.

Sprint Review vs Sprint Retrospective

Each sprint ends with a two-part sprint review meeting. Such a meeting starts with a customer review and demonstration and ends with the team retrospective. Both of these components occur on the last day of the sprint.

The Sprint Review focuses on the “inspect” and “adapt” of the increment (Potentially shippable), while the Sprint Retrospective give more focus on the “inspect” and “adapt” of the process of the sprint.

Sprint review vs Sprint retrospective

Sprint Increment Review

The Scrum teams will ask customers to review whether the work demonstrated (potentially shippable) meets the definition of done at this point, or sometimes, some customers may want time to use the application for some time prior to the acceptance made. The goal of the meeting is to review transparently and determine the status of the work implemented in the sprint:

has been done
has not been done
work that has been added
And work removed from the sprint

It offers the time to ask questions, make observations or provide feedback and suggestion, and have discussions about how to best move forward in the given current realities.

Duration of Sprint Review

A sprint review may last up to 4 hours in 4-week-sprints. The general rule is that the sprint review should take no more than one hour per week of sprint duration. The following table illustrates the rule.

Total Sprint Duration	Sprint Review Duration
1 week	1 hours
2 week	2 hours
3 week	3 hours
4 week	4 hours

Sprint Review Meeting Template

There are many ways for conducting a Sprint Review. The sprint review meeting agenda below outlines the activities within a typical Sprint Review meeting:

Start – Sprint Review Meeting starts
Welcome the Stakeholders – Product Owner welcomes the stakeholders to attend the review
Present Review Agenda – Product Owner presents the agenda for the Sprint Review
Present Product Increments – Development Team present the product demo that have been implemented in the Sprint
Get Feedback – Product Owner asks the stakeholders for feedback regarding the product that have been delivered
Present Product Backlog – Product Owner presents the top of the Product Backlog to stakeholder to get feedback for the upcoming Sprint(s) and solicit feedback from the stakeholders related to the backlog
Meeting ended

About Visual Paradigm

Visual Paradigm help organizations stay competitive and responsive to change faster and better in today’s fast changing environment. Our award-winning products are trusted by over 320,000 users in companies ranging from small business, consultants, to blue chip organizations, universities and government units across the globe. It enables organizations to improve business and IT agility and foster innovation through popular open standards and process frameworks.Visual Paradigm, a killer Agile feature in 2018, introduced Scrum Process Canvas for automating the way a Scrum team to create, manage and deploy software application that empowers the team to continuously improve their performance at unprecedented speed and scale.

Manage the Entire Scrum Process in One Page

Automate the Scrum Framework in a fun and enjoyable dashboard with eye-catching updated status.
Manage Backlog, Multiple Sprints of different Scrum Roles with a single-page visually executable canvas
Allow instantly access, review and generate scrum artifacts and related documents to be archived in the Shared Cabinet
Automate the Scrum events and related activities with self-explanatory instructions, samples and required document templates.

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.

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.

Source: Scrum.org

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.

Source: Renata Blicharz

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.

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.

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.

Source: Anca Onuta

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 meeting agenda example

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