You are on page 1of 1

Sprint Review or Iteration Review

Purpose:
The Sprint Review starts by going over the Sprint goal and discussing their status. It then proceeds
with a walk through of all the committed stories. Each completed story is demoed as part of a
working, tested system preferably in staging environment that closely resembles the production
environment. Spikes are demonstrated via a presentation of findings. Stakeholder provide feedback
on the stories that are demoed, which is primary goal of the review process. After the demo the
reflects on which stories are not completed, if any and why the team was unstable to finish them.
This discussion usually results in the discovery of impediments or risks, false assumptions, change in
the priority, estimating inaccuracies, or over commitment. These findings may lead to further study
in the iteration retrospective and the identification of improvements to support better planning and
execution in future iteration.

Agenda:
1. Sprint goals and outcomes
2. Demo of delivered functionalities (focus on “fit for purpose”).
3. Discussion of challenges, such as technical liability and factors that prevented the team to
achieve its objective, including emergency break down and absence.
4. Delivered impact of functionality in relation to current priority and/or Vision
5. Discussion of the next sprint

Who attends?
Product owner role during the Iteration demo
1. Check that what is delivered in the sprint match and sprint goal.
2. Check if the acceptance criteria are met.
3. Accept or reject the delivery.
4. Provide feedback to the team.
5. Answering questions from the team and other stakeholders.
6. Identify new requirements and needs, its not uncommon for new requirements emerged
during the demo.
7. Plan ahead for the next sprint.
8. Suggest ways to the functionality better and thus increase further.

Team members role during the sprint demo

1. The members who work on the story QA or DEV can demo the story to the PO and Team.
2. Team members can ask the question, dive into how the code works and get cross training on
the story that was implemented

Scrum Master role during the sprint demo

1. The SM ensure the team does not get off the topic or ensure this does not become session
where we spend an hour diving into the code.
2. The SM will talk about the velocity of the sprint and why team delivered the amount they
did.

You might also like