Based on the Ken Schwaber and Jeff Sutherland definition of Sprint Review, in this document you will find some common gaps and how we can avoid it

1. Why we say “Review Meeting” when we are really
doing a “Demo”?
Each words that we are using have a specific meaning, each event has its own
motive and knowing the name of each event the attendees know what they are
going to find. It is necessary to define every relevant agile, Scrum, and software-
development term that the team is used. This is one of the Empirical
Process pillars, Transparency, when all the team understands the same.
“A Sprint Review is held at the end of the Sprint to inspect the Increment and
adapt the Product Backlog if needed.”
The focus of the sprint review is to inspect and adapt the product increment that
was produced during the sprint. We inspect what was just built and, based on the
feedback that we get from our stakeholders, we can adapt what we build next by
Sprint Refinement Meeting the product backlog.
“During the Sprint Review, the Scrum Team and stakeholders collaborate
about what was done in the Sprint.”
In some Scrum Teams, the Sprint Review is used to get the Product Owner’s
feedback, then the Sprint Review becomes a kind of ‘Acceptance’ event and not A
Sprint Review Meeting. In such Sprint Reviews often no stakeholders are present.
The Product Owner is the only person to give feedback. Here is the gap: The
Product Owner is also part of the Scrum team. Feedback from the Product Owner
must always be processed during the Sprint. After all, if you do not process P.O.
feedback within the Sprint then you consciously postpone work to the next sprint.
And, even worse: you actually prevent that the product is really finished at the end
of every Sprint. If the Development Team wants to show or explain any detail about
one user story they can plan a specific meeting for that. If the Product Owner wants
to know which is the Sprint’s current status, he might see it in the Scrumboard. If
any stakeholder wants to know which is the Sprint’s current status, he could take a
look to the Scrumboard (if he/she has access) or should ask to the Product Owner.
“Based on that and any changes to the Product Backlog during the Sprint,
attendees collaborate on the next things that could be done to optimize
value. This is an informal meeting, not a status meeting, and the presentation
of the Increment is intended to elicit feedback and foster collaboration. This
is a four-hour time-boxed meeting for one-month Sprints. For shorter Sprints,
the event is usually shorter. The Scrum Master ensures that the event takes
place and that attendants understand its purpose. The Scrum Master teaches
all to keep it within the time-box.
The Sprint Review includes the following elements:
 Attendees include the Scrum Team and key stakeholders invited by
the Product Owner; “

2. In the meeting the Scrum Team test whether the ideas they have are correct. This
test is done with all stakeholders that have an interest in the software. That is why
the Product Owner invite all stakeholders to attend the Sprint Review. The
meetings consists of many checks and tests to see if you we are on the right track.
 The Product Owner explains what Product Backlog items have
been “Done” and what has not been “Done”; “
The first step is to review the goal and committed/forecasted features and compare
that to what actually got accomplished during the sprint
 The Development Team discusses what went well during the Sprint,
what problems it ran into, and how those problems were solved; “
The meeting is crucial to learn what a team has misunderstood or what has been
forgotten.
 The Development Team demonstrates the work that it has “Done”
and answers questions about the Increment; “
The demonstration is useful to the extent that it enables a thoughtful discussion on
what we just built and its ability to inform any changes we would like to make for
what we will build in the future. The real purpose of the demonstration is to enable
the next two steps: discuss and adapt.
 The Product Owner discusses the Product Backlog as it stands. He
or she projects likely completion dates based on progress to date
(if needed); “
During the Sprint Review all stakeholders are present. This is the place to show
them what you plan to do. Why wait until the end of the next Sprint to get their
feedback? In the Sprint Review meeting let the Product Owner show the Product
Backlog and embrace the feedback from the stakeholders
 The entire group collaborates on what to do next, so that the Sprint
Review provides valuable input to subsequent Sprint Planning; “
A demo of working software may be a good trigger for such feedback. It is for end
users awfully difficult to give feedback on software through reading a document.
But giving feedback on real working software is much easier. In other words, you
will understand it only when you see it.

3.  Review of how the marketplace or potential use of the product
might have changed what is the most valuable thing to do next;
and,
 Review of the timeline, budget, potential capabilities, and
marketplace for the next anticipated release of the product.
The result of the Sprint Review is a revised Product Backlog that defines the
probable Product Backlog items for the next Sprint. The Product Backlog
may also be adjusted overall to meet new opportunities.”
The most important aspect of the sprint review is the in-depth conversation and
collaboration among the participants, not the demonstration. These discussions
enable productive adaptations to surface and be exploited. A review isn't a one-way
flow of information, where the team is doing all of the showing and telling. It's an
opportunity for the Scrum team members to get feedback from customers or users.
The sprint review therefore represents a scheduled opportunity to inspect and
adapt the product.