Sprint Review Meeting

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 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 stakeholders understand it.

• Functionality that isn ‚ t ‚“done ‚½ cannot be presented.

• Artifacts that aren ‚ t 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 be 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 assurance (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 didn ‚ t go well in the Sprint.

• The majority of the Sprint review is spent with Team members presenting functionality, answering stakeholder questions regarding 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 rearrangement of the Product Backlog based on the feedback.

• Stakeholders are free to voice any comments, observations, or criticisms regarding the increment of potentially shippable product functionality between presentations.

• Stakeholders can identify functionality that wasn ‚ t delivered or wasn ‚ t delivered as expected and request that such functionality be placed in the Product Backlog for prioritization.

• Stakeholders can identify any 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 ScrumMaster 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 ScrumMaster announces the place and date of the next Sprint review to the Product Owner and all stakeholders.