Last updated on | Scrum General Knowledge

What Is Sprint Review Meeting and How To Hold Absolutely Interesting One

by Luís Gonçalves
Sprint Review Meeting

Sprint Review meeting is carried out once the Sprint has been done. It is meant to inspect the Increment and adapt the Product Backlog if necessary. When the Sprint Review meeting is taking place, the Scrum team and stakeholders evaluate what has been done during the Sprint.

The review serves for sharing information, this is not a status meeting. It is solely held to get some feedback as well as ensure that there is collaboration.

During a Scrum, regular sprint review meeting is schedule to demo and determine the product usability. Teams are expected to deliver a shippable product during each increment or Sprint.

To ensure their success, sprint review meeting is held at the end of each sprint. During the review, the Scrum team shows to the stakeholders what they have accomplished by demonstrating the newly designed features.

Sprint review meetings are deliberately informal. Programs like PowerPoint are forbidden and a preparation time limit of 2 hours maximum is set. These meetings are not, nor should they be viewed as a distraction or major detour for the team. Instead, they should be a natural transition and result of the sprint session.

Typically, the Scrum Master, members of the management team, the product owner, customers, developers from other projects, and the Scrum team participate in the sprint review meeting.

A goal for the software is set in the sprint planning meeting. Achieving this sprint goal is very important. To ensure this has been done, the delivered project is assessed and compared to the goal during the sprint review. Each product backlog is also brought into the review to ensure that the goal has been met.

Sprint Review Meeting

In a Sprint Review meeting, the Scrum Team and stakeholders discuss the work done during the Sprint. After assessing the work done along with changes made to the Product Backlog, the group collaborates on what steps should be taken next to optimize the value of the software. These meetings are always intentionally informal to keep the group focused on encouraging feedback and collaboration.

For month-long Sprints, review meetings should last a maximum four hours; referred to as time-boxed sessions. If the sprint sessions are shorter in duration, the review meetings will also be shorter. The Scrum Master is responsible for scheduling the meeting and informing everyone attending of the purpose of the review. The Scrum Master is also responsible of ensuring the meeting stays within the time-box.

The Sprint review meeting should include the following:

  • Attendance and participation of the Scrum Team, product owner, and invited key stakeholders.
  • The Product Owner should report the items in the Product Backlog; what backlog items have been done and what have not.
  • The development team discusses what went well and the problems they experienced. They should also inform the group what they did to resolve the problems.
  • The development team demonstrates their completed work while answering questions about their increment.
  • The product owner leads the discussion on the Product Backlog as it currently stands. They set projected completion dates based on the progress of the Sprint session.
  • To give valuable input to the Sprint planning, the entire group establishes the next steps during the Sprint review meeting.
  • This is a time to review potential changes in the marketplace, the valuation of the project and what areas are considering to be the most valuable. The next steps should also be outlined.
  • Review the timeline, budget, potential capabilities, and marketplace to determine the next anticipated product release.

By the end of the Sprint Review, revisions should be made to the Product Backlog to better define probable backlog items for the next Sprint session. The Product Backlog can be adjusted completely to introduce new opportunities.

Focus on the End User

Companies can be reluctant to involve end users for several reasons: some fear of scope creeping, others believe they are not allowed to ask the end users to get involved while some do not know who their end user is. End users are a vital part of the session. Never find an excuse not to involve them!

Involve the Product Owner

Too often, many companies organize their sprint reviews as a team presentation for the product owner to grade or judge their work. This format is complete nonsense! Sprint Reviews are not legal inquisitions or courts, they are an informal meeting designed to gain the customer’s feedback. Rather than presenting their data to a judge-like product owner, teams should collaborate with the product owner to review each completed story.

At the beginning of the sprint review, the product owner should stand first to welcome everyone and provide a project overview. The owner can then discuss the goals of the Sprint: what were achieved and what goals were not. It’s also a good time to talk about the quality level of the product, the software’s release, and product burndown. The owner can pinpoint what the reviewers should be looking for and explain to the team how to give their feedback. After they finish their introductory statements, the product owner can turn the meeting over to the Scrum team for a demonstration on the software’s functional abilities.

Understand Group Dynamics      

The group dynamics are altered significantly when the focus of the meeting changes from a lone product owner to a group collaboration that includes the Scrum team, stakeholders, and the end users.

When the product owner becomes part of the presenting team, the above roles change. Here’s a look at how each group is affected:

Product Owner

The Product Owner’s role changes to that of the real owner of the product. As a key member of the team, the owner becomes more responsible and accountable for the product. Their answerable for the decision-making and for presenting the results to the end users and stakeholders. He stands up and presents the product increment and gives insight into the state of the project.

By changing the role, the owner understands that he/she becomes more disciplined in maintaining the product design, release burndowns, and setting a level of quality for the work.

Another noticeable byproduct of this change is that discrepancies can be seen immediately. If the owner’s perceived reviews of the end users’ needs do not match the actual needs, it will become immediately noticeable.

Scrum Team

The Scrum team has a greater sense of pride and accomplishment and is better positioned to demonstrate their work to the group. They are allowed time to the end user, and, in the best-case scenario, meet with the end users face-to-face time. Knowing the end user is the best way to develop quality software that will offer the highest value to the end user. By learning to accept feedback at each sprint session, the team gains more appreciation for the product owners and customers. The team will also feel less like they are being judged or graded by the product owner. They will come away from the meeting feeling more energized and motivated towards the next sprint.

Company Executives/Stakeholders

When executives and stakeholders are part of the review meeting, they can see the team work while participating in a real review of the work done and actions taken. Additionally, the end users can personally inform the executives/stakeholders of their needs.

Most importantly, they learn to act appropriately. The dynamics of these meetings are significantly different when customers are part of the session. When end users are present, executives and stakeholders spend less time bickering and criticizing others. Instead, everyone is on their best behavior, ensuring the review is more motivated and productive.

End Users/Customers/Partners

Without question, the end users are the stars of the review meetings because the spend valuable face-to-face time with the software developers. They spend so much time with the developing group, the end users feel as sense of belonging. Because they spend so much time and involvement in the development of the project, the users become the biggest company supporters. This acquired knowledge is valuable in reducing in flood of support calls that are common after a release.

Scrum Master

The Scrum Master facilitates the sprint review. This person establishes an environment among all members so that great accomplishments and goal achievements can happen. To make it happen, the Scrum Master must make sure the right people are at the meeting. He/she must also ensure the right room and supplies are readily available.

Other smaller details like ordering food and drinks is also the responsibility of the Scrum Master. While this may seem unimportant to some, food is fuel that teams need to continue their hard work during the meetings. Personally, I have ha many great conversations with teams while eating together.

One thing to keep in mind, this is not the Scrum Master’s show – they are not the star. The Scrum Master is there to support the team. They also welcome the end users and make sure they are included in the team, have the chance to be heard, and are behind the scenes.

Be Courageous

To master the art of feedback, you must first create an environment that allows open feedback to happen. Involving the end users in the sprint reviews can be scary, but remember: hearing the feedback early gives you time to make the needed adjustments. Waiting until the end to find discover you went down the wrong path is a waste of precious time and resources. So, if you’re still afraid of scope creep, let it go. During the review, the Product Owner will first decide what trade-offs will make after each sprint review. You can use this opportunity to find out more about what the end users need and do not need; this helps reduce and eliminate overproduction of some features that will never be used.

By focusing on the end user, and creating an energy and excitement, you will create a sprint review that customers will want to attend. It’s easy to do; simply set up a review that offers direct value for the end user. Once that is done, just sit back, and listen. You will be surprised what you learn.


We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.

Take The Test

If you liked this article, feel free to visit my company Products and Services pages.

We provide Team CoachingAgile Training, and Agile ConsultingOKR TrainingOKR ConsultingInnovation Training and Innovation Consulting.

With my team, I built 5 main products: High Performing TeamsScrum Team CoachScrum Master MentoringOrganisational Mastery and the External Business Accelerator.

Rate this post:
Luís Gonçalves

About Luís Gonçalves

Luis Gonçalves is an Entrepreneur, Author & International Keynote Speaker that works exclusively with Senior Executives of 7 to 8 figure businesses on the deployment of his game changing ‘Organisational Mastery’ Methodology.


Share your point of view

  1. Hello Luis,

    thank you for the great blog post.

    However I think you mixed something up here. When you write about the “Scrum Team” I think what you really mean is the “Development Team”, as the “Scrum Team” consists of PO, SM and DevTeam 🙂

    Please keep up your great work 🙂


  2. Hi Luis,
    Thanks for the blog post. The post focuses on a single team review but my company has Release-Train sprint reviews. We have 8 teams present over 90 minutes and all the stakeholders are there the whole time. All the teams are working on similar things and We are struggling with engagement/feedback from the stakeholders (all internal). Do you have an experience with larger sprint reviews? What tips do you have for making this format more engaging without wasting people’s time?

  3. Thank you for this article and for share all this knowledge. Really good. Gave me nice ideas to use with my team sprint review. And also congratulations to your work.

  4. Luis, the majority of the work we do requires User Research to take place prior to development. We have a user research teach (Design) who perform UR and bring back design and update a prototype at the end of the Sprint.

    The prototype form the basis of the main discussion with stakeholders in the end of sprint review. This forms our main interaction with stakeholders and it’s their time to discuss and change the design where required.

    In the meantime the Dev team will have developed the prototype from the previous design sprint. However as the stakeholders have already seen the prototype, the development review in most cases becomes a formailty.

    As more and more software development involves User research and design cycles running in tandem, We need to evolve scrum to reflect this practice.

    1. Shouldn`t be the other way around? Having the UR give feedback even before the development starts?

      That`s how I did it in the past, especially now with tools like Google Design Sprint I see having UR after development a waste of time and money.