The sprint review is the Scrum event held at the end of each sprint in which the development team demonstrates working-software to stakeholders and the product owner. It is an inspection event: the team shows what was actually built, stakeholders respond, and the product backlog is updated to reflect new understanding. In scrum, it is timeboxed at four hours for a one-month sprint.
ken-schwaber and jeff-sutherland included the sprint review in Scrum from its earliest formulations. The scrum-guide is explicit that the sprint review is not a status meeting and not a sign-off ceremony — it is a collaborative working session in which the product's future direction is adapted based on what was learned.
Intellectual Contribution
The sprint review operationalizes the foundational Agile claim that working-software is the primary measure of progress. Rather than reporting on tasks completed or percentage-done estimates, the team demonstrates software that runs. This is the inspect-and-adapt cycle at the sprint boundary: actual software, actual stakeholders, actual feedback.
The practice challenges the traditional project management model in which the customer sees the product only at the end — when changes are expensive and scope is locked. By showing working software every one to four weeks, the sprint review creates a regular mechanism for requirement discovery: stakeholders often do not know what they want until they see working software. This is the Agile answer to the fundamental specification problem.
The sprint review also closes the accountability loop without bureaucracy. Rather than status reports and milestone gates, the demonstration is evidence. A feature either works or it does not; it meets the definition-of-done or it does not. This directness is part of what made Scrum attractive to teams frustrated with reporting theater.
Common Failure Modes
In practice, sprint reviews are frequently skipped, abbreviated, or converted into internal demos (the team shows work to themselves). This failure mode strips the event of its core purpose: the feedback from stakeholders outside the team. Without genuine external perspectives, the product risks being built to the team's assumptions about what stakeholders want rather than their actual expressed preferences.
The distinction between the sprint review (external inspection, product focus) and the retrospective (internal reflection, process focus) is important: they address different questions and should not be merged.
Related practices: sprint-planning, daily-standup, retrospective, acceptance-criteria, definition-of-done.