What is a Sprint Review / Demo?

The Sprint Review, sometimes known as the Sprint Demo, occurs at the end of the Sprint where the Delivery Team reviews and demonstrates the work performed during the Sprint. Completed work can be demonstrated, planned work that was not completed can be reviewed and additional information can be gathered from stakeholders.

The Sprint Review can be a motivational team building ceremony since the Delivery Team and the Stakeholders are together. The Delivery Team gets to showcase the work and the Stakeholders provide direct feedback.

What’s the Benefit?

The benefit of the Sprint Review is the team inspects the progress of work performed during the sprint directly with stakeholders and can adapt to new information in upcoming sprints. Having the team get feedback directly from stakeholders is critical and offers the benefit of allowing the team to showcase the work delivered.

When?

Sprint Reviews occur at the end of every Sprint before the Retrospective. Information gathered during the Sprint Review can be a critical input for Sprint Planning.

Who attends?

• Scrum Master (May be the facilitator)
• Product Owner (May be the facilitator)
• Stakeholders
• Entire Team
• Product Manager, if the team’s work aligns with Product Management (Decision Maker)

Inputs

• The Sprint Backlog from the most recent Sprint
• Working product

 Outputs

• Alignment of Stakeholders and Team
• Feedback for planning, including new User Stories and adjustments to the Team Backlog as needed

Preparing for Success

Team Preparation

Team members should be prepared to demonstrate completed work and review uncompleted planned work. The Team’s focus should be on the actual work and not slides. Acceptance Criteria may be reviewed, and the Team should ensure at least one person is prepared to discuss every item, completed or not.

Facilitator Preparation

Since the Product Owner (PO) is closest to the stakeholders and customers, facilitation may be shared with the Scrum Master. Responsibilities should be agreed upon and invitations should be sent to stakeholders as a reoccurring ceremony.

The facilitator should be prepared to show a list of all Stories or Backlog Items committed during Sprint Planning or added during the Sprint. This can be done through the Application Lifecycle Management (ALM) tool or a created document.

Location

This should be a comfortable space where open discussion can take place. Communications with remote Stakeholders and Team members is key.

Materials

A way to display the User Stories, Acceptance Criteria, Features and working software is needed.

Execution

1. The facilitator discusses the Sprint Goal
2. Each Story and Backlog Item is reviewed and demonstrated if appropriate.
3. Feedback should be gathered and documented for each item with a focus on action items.
4. Requests for changes to the working product should go into the Backlog and may or may not, become part of the upcoming Sprint.

 Best Practices

• The Sprint Review should occur at the end of the of the Sprint and before the Retrospective.
• All work should be reviewed even if the work was incomplete.
• Since the focus should be on the work, presentation materials and preparation should be kept to a minimum. Typically, no more than one-hour of prep time per Sprint.
• Conversation should be encouraged. If feedback seems limited, the Product Owner should reach out to individual stakeholders and customers after Sprint Planning.
• The ceremony should be regularly scheduled to ensure stakeholders and customers have ample time on their schedule.
• If long discussions are taking place, the Product Owner may schedule additional time to follow up with stakeholders.
• The Product Owner should only commit to adding items into the Backlog and not commit to changes being made in the upcoming Sprint as the Delivery Team should have input.