A Sprint Review/Demo meeting is held at the end of the Sprint to inspect the Increment. The Team demonstrates the Increment with focus on the Sprint Goal according to the Definition of Done. The Product Owner reviews and accepts the delivered Increment.

Meeting Specifics

Time-box :

• 1.5 hours (2 weeks sprint) / 3 hours (4 weeks sprint)

Attendees :

• Scrum Master
• Product Owner
• Scrum Team
• Stakeholder and Sponsors
• Customer

How is the meeting held?

The development team presents the results of the Sprint. The Product Owner reviews and accepts the delivered product increment. During the Sprint Review Product Owner, Development Team and stakeholders review what was done. Typically this takes the form of a demo of the new features. The Scrum Team goes through the forecasted Product Backlog items and reviews how the requirements (user stories) have been realized in the product increment.

After the demonstration, the Product Owner and other relevant stakeholders tell their impressions and clarify their requirements (user stories) if a requirement was not implemented right. The Product Owner identifies what has been done and what hasn’t been done (according to the Definition of Done). The Product Owner accepts the user stories that have been done.

Results of this meeting can be new requirements in the Product Backlog, and a new prioritization of existing Product Backlog items.

What are the objectives of the Sprint Review Meeting?

The purpose of the meeting is for the team to show the customers and stakeholders the work they have accomplished over the sprint. The meeting is facilitated by the product owner but it is not uncommon to have the team members run the meeting. In this meeting, the customers (PO) should review the following data :

• The work committed by the team
• The actual work completed by the team
• Key decisions made during the iteration/sprint (this may include technical, market-driven, requirements, etc.,)
• Project metrics (code coverage, etc.)
• Demo of the work itself
• Priority review (for the next iteration/sprint)

What should be the focus in Sprint Review Meeting?

• The Scrum Master should make sure the sprint review is about the process or the product or product increment, not about people.
• Stakeholders should operate as a team, rather than as individual subject matter experts.
• The product owner should encourage the team to maintain a steady pace during the product walk-through.
• The product owner should avoid the temptation to formulate solutions. The team should formulate and agree on possible solutions.
• The product owner and Scrum Master should focus the review on the product or product increment presented and not drift into the discussion of other products or areas.

Tips for holding the Sprint Review Meeting

1. Let everyone know why there’s a Sprint Review

Start by making sure that everyone, including the stakeholders, knows the reason for the Sprint Review – that is, it’s a collaborative working session where the team will showcase its work and everyone will look at the working software produced during the Sprint.

2. Send a team reminder

Remind the team before Sprint Planning that there will be a Review at the end of the Sprint and describe what to expect. The team should be able to show :

• An overview of how the Sprint went
• The “done” items as working software
• Which items are not done and that they’re now back on the Product Backlog. This is designed to ensure that no hidden work is undone (technical debt)

3. Ask the team how it’ll showcase its work

The team should consider ways and methods how it can best showcase the completed work. It could consider demonstrating relevant subsets of acceptance tests collectively, or alternatively, each team member could volunteer to demonstrate one User Story each.

4. Help the team prepare

The team should take the ownership of the work it’s responsible for. Leaders should step aside and help the team to self-organize by facilitating the process.

The Scrum Master should ask questions such as :

• What does the success of the Review look like?
• What’s the next step?
• How will we know we’ve achieved that?

5. The Product Owner should educate him/her self

The Product Owner should :

• Understand each User Story properly.
• Be clear on the acceptance criteria.
• Able to ask meaningful questions.
• Be ready to discuss the Product Backlog as it currently stands including what the next highest priority items are.
• He/she could also use this meeting as an opportunity to remind the team of the Release Goal.
• Remembering the big picture can be immensely valuable.

6. Watch the clock!

It amazing to know that many companies use a time-boxed framework like Scrum but still don’t have a wall clock in the meeting room! A clock should be made available if it’s not there in the working room.

7. Respecting the time box

A self-organizing team should open the meeting with a quick check-in round where everyone quickly says how they’re feeling and what’s on their minds. The team should outline the aim of the meeting on a whiteboard and start with the proceedings as soon as possible. The meeting is time-boxed so every minute counts for the team.

8. Make time to discuss the next move

The Product Owner should be able to discuss the Product Backlog as it currently stands and then invites open discussions about whether it is what the team should do next. Is there a more optimal way? If so, how can the team measure this? Ultimately, the Product Owner has the final call, but anyone with a vested interest in the project should be present as this is a great opportunity for discussion.

9. Record the results

Don’t forget to record the main points of what was agreed.