The Sprint Review is where the Scrum Team and its key stakeholders inspect the results of the Sprint together and work out what should happen next. It is the second to last event of the Sprint, timeboxed to a maximum of four hours for a one month Sprint and usually shorter for shorter Sprints.
The most useful thing to know about it is what it is not. It is not a gate the Increment passes through, and it is not the moment at which work becomes Done.
What is actually inspected
The Scrum Team presents the results of its work, and progress towards the Product Goal is discussed against the evidence now in front of everybody rather than against a plan. Attendees also review what has changed outside the team since the last review, because a competitor release, a change in regulation or a shift in what customers are asking for alters what the next Sprint should contain as much as anything the team built.
Out of that comes a decision about what to do next, and the Product Backlog is adjusted to reflect it. That adjustment is the real output of the event. If nothing in the backlog looks different afterwards, either the team learned nothing or nobody wrote it down.
Why it is not an approval step
Nothing in Scrum makes the Sprint Review a sign off. An item is Done when it meets the Definition of Done, which the Scrum Team applies as it works, rather than when a stakeholder gives a verdict at the end of the fortnight. The Increment may well have been released days earlier, since Scrum allows work to go to stakeholders as soon as it meets that standard.
Treating the event as approval creates a queue. Finished work waits for somebody to bless it, feedback that would have changed the work arrives after it is built, and the team has spent a Sprint on something nobody looked at until the end.
What the four hours are protecting
Four hours is a maximum for a one month Sprint, and the event scales down with Sprint length so that the ratio of inspecting to building stays roughly constant. It is a ceiling rather than a target.
The timebox protects the stakeholders as much as the team. A review long enough to walk through every item in the Sprint Backlog will be filled that way, and the people whose attention the team most needs will stop coming. Showing the work that bears on the Sprint Goal and the Product Goal, then spending the rest of the time on what to do next, is what keeps the room worth attending.
Who is in the room, and who still decides
The Scrum Team attends and key stakeholders are invited. Which stakeholders count as key is a judgement the Product Owner makes, and the test is whether the person in the room can change the next decision or is merely being kept informed.
Collaboration on what to do next is genuine, and the ordering of the Product Backlog afterwards remains the Product Owner's accountability. Stakeholders influence that ordering and they do not vote on it. A Product Owner who reorders the backlog to match whoever spoke loudest has not collaborated, they have handed the decision away.
What Scrum leaves open
There is no prescribed agenda, no required format and no rule about who does the talking. Whether stakeholders try the product for themselves, whether the Developers or the Product Owner walk through the work, and whether the team gathers a satisfaction measure afterwards are all for the Scrum Team to decide. What is fixed is that the results are inspected with the people affected by them, and that the Product Backlog may change as a result.