Sprint Review
No more than 4 hours should be spent reviewing long sprints. For one- or two-week sprints, one or two hours should be enough.
Objectives
- The Product Owner checks the progress of the system. At regular intervals, this meeting sets the pace of construction and shows the direction the product vision is taking.
- The Product Owner identifies which features can be considered "done" and which cannot.
- By seeing and trying out the increment, the Product Owner and the team as a whole obtain relevant feedback for revising the Product Backlog.
Other engineers and programmers in the company may also attend to learn how the technology being used works.
Preconditions
- The sprint has ended.
- The entire development team, the Product Owner, the Scrum Master, and anyone involved in the project who wishes to attend are present.
Inputs
An increment that is done and meets the Definition of Done.
Outputs
- Feedback for the Product Owner: a tracking milestone for the construction of the system and information to improve the value of the product vision.
- Call for the next Sprint Planning.
Meeting format
It is an informal meeting whose purpose is to see the increment delivered.
- Graphic presentations and slides are prohibited.
- The team should not spend more than one hour preparing the meeting.
- What is shown is the final result: done, tested, and running in the development server environment (labs) or in production.
It is common for each developer to explain the user stories they planned, the ones they have developed, the ones they have not, and the impediments they encountered. The review is also a feedback point for uncompleted stories: the reasons are analyzed, and their estimate is reconsidered if necessary.
This meeting sets, at regular intervals, the pace of construction and the direction the product vision is taking, allowing stakeholders to contribute suggestions for its continued evolution.
Difference from the Sprint Retrospective
- The Sprint Review examines what has been built: the increment, the completed stories, and the product feedback.
- The Sprint Retrospective examines how it has been built: the process, the collaboration, and the ways of working.
Both meetings are held at the end of the sprint, but with different goals and usually with different attendees (external stakeholders attend the Sprint Review, not the Sprint Retrospective).
Common mistake
Showing incomplete features or features that have not met the Definition of Done. The Sprint Review should show only what is truly done according to the agreed DoD. Showing half-finished features gives a distorted picture of actual progress, creates false expectations for the Product Owner, and erodes trust. If something is not done, it is not shown.
Resources
📄 Product Owner v.2.0Free download (in Spanish) · Scrum Manager
📄 Scrum Master v.4.0Free download (in Spanish) · Scrum Manager
See also
Do you want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.