Time-Boxed to 4 hours
Team presents to the Product Owner & Stakeholders the functionality that is done. Done means code is completely engineered and could be shipped or implimented.
- Team should not prepare for the review for more than 1 hour.
- Functionality that isn't done cannot be presented.
- Artifacts that aren't functionality cannot be presented except to support understanding of demonstrated functionality.
- Use of Artifacts must be minimized so as to avoid confusing stakeholders or requiring them to understand how system development works.
- Functionality should be presented on Team member workstations and executed from the server closest to production --usually a QA (quality assurance) environment server.
- Sprint Review begins with a team member presenting the Sprint goal, Product Backlog committed to, and Product Backlog completed. Different Team members discuss what went well and what did not go well with the Sprint.
- The majority of the Sprint is devoted to Team members presenting functionality, answering stakeholder questions and noting desired changes.
- At the end of presentations, stakeholders are each polled as to their impressions, changes and priority of these changes.
- Product Owner discusses potential changes to the Product Backlog based on feedback.
- Between presentations stakeholders can ask or comment on any aspect of the Sprint Backlog under scrutiny.
- Stakeholders can request that new functionality or Sprint Backlog that wasn't delivered or delivered as expected during the current Sprint be placed or added to the Product Backlog for prioritization.
- ScrumMaster will plan for the meeting with emphasis on meeting attendees needs gracefully.
- ScrumMaster announces the next meeting location and date of the next Sprint Review at the close of the meeting.
Summary
