Sprint Review or Product Demo
The team demonstrates to the Product Owner (and others) the accomplishments of the sprint.
Purpose of the Sprint Review
In Ken Schwaber's article, [http://www.scrumalliance.org/articles/31-no-applause-please No Applause, Please], he states
- "The sprint review is designed to be the Product Owner’s inspect-and-adapt point for optimizing return on investment. Based on the Product Owner’s goal, he or she inspects and adapts what has been built. In consultation with the team and other significant stakeholders, the Product Owner then restructures the product backlog for the next sprint. The purpose of the sprint review is to cause this interaction between the Product Owner, the people he or she represents, and the team. Collaboration, further exposure of salient information, and brainstorming should occur so that decisions are made with the best information possible."
A way to make a good Sprint Review
In Bob Schatz' article, [http://www.scrumalliance.org/articles/48-successful-sprint-reviews Successful Sprint Reviews], he states
- "The one sure fire way to have a good sprint review is to tell a story. You develop the theme in sprint planning by stringing together backlog items and weaving a plot with the user stories. Then you implement these features, testing them based on the story. Next, you bring that story to the sprint review, giving life to the software. Use real characters and locations; make connections with people and the value that the software provides. A well-developed story will stick with people long after the sprint review. A good sprint review story has the following components:
- A meaningful; relevant theme;
- A sequence of events as the user would experience them;
- Characters and data that is realistic—use examples and names from your user community or members of the development team;
- Is compelling to the people attending the review;
- Is relevant to the people in the review; and
- Is at an appropriate technical level for attendees."