The sprint review meeting is time boxed to 4 hours
- The team should not spend more than 1 hour preparing for the sprint review
- The purpose of the sprint review is for the team to present to the product owner and the stakeholders functionality that is done. Although the meaning of ‘done’ can vary from organization to organization, it usually means that the functionality is completely engineered and could be potentially shipped or implemented. If ‘done’ has another meaning, make sure that the product owner and the stakeholders understand it.
- Functionality that is not ‘done’ cannot be presented
- Artifacts that are not functionality cannot be presented except when used in support of understanding the demonstrated functionality. Artifacts cannot be shown as work products, and their use must me minimized to avoid confusing stakeholders or requiring them to understand how systems development works.
- Functionality should be presented on the team member workstations and executed from the server closest to production – usually a quality (QA) environment server.
- The sprint review starts with a team member presenting the sprint goal, the product backlog committed to, and the product backlog completed. Different team members can then discuss what went well and what did not go well in the sprint.
- The majority of the sprint review is spent with team members presenting functionality, answering stakeholder questions ragrding the presentation and noting changes that are desired.
- At the end of the presentations, the stakeholders are polled, one by one to get their impressions, any desired changes and the priority of these changes.
- The product owner discusses with the stakeholders and the team potential re-arrangement of the product backlog based on the feednack.
- Stakeholders are free to voice any comments, observations or criticisms regarding the increment of potentially shippable product functionality between presentations.
- Stakeholders can identify new functionality that occurs to them as they view the presentation and request that the functionality be added to the product backlog for prioritization.
- The scrum master should attempt to determine the number of people who expect to attend the sprint review meeting and set up the meeting to accommodate them.
- At the end of the sprint review, the scrum master announces the place and date of the next sprint review to the product owner and all stakeholders.
from ‘agile project management with scrum’ by Ken Schwaber