Sprint Review¶

Purpose: A sprint review is about demonstrating the hard work of the entire team: designers, developers, and the product owner. Sprint reviews protect the health of both the team and project.

The review is not an exam—it’s a collaborative event across the team in which people demo their work, field questions, and get feedback.

If a sprint review doesn’t become a positive activity across the team, it may be indicative of:

• The team taking on too much work and not completing it during an iteration
• The team struggling with existing technical debt
• The team’s development practices aren’t as tuned as they could be
• The development team is sidelined by scope creep
  Note: every team has a difficult iteration sometimes. Take the time to understand why an iteration changes in the team’s retrospective and create a plan to address issues in the next sprint.

How to run a Sprint Review¶

Pre-Sprint Review

1. Have everyone update their User Story tasks to their correct status, any blockages, and how many hours it took. Do not have them touch the user story's themselves (status's or story points) this will be done during the review.
2. Tell them to prepare a short, effective demo or discussion about their work that will be conveyed to the team during the review.

Sprint Review

1. Emphasize these meetings are a celebration of work.
2. Go through each individual and have them give a quick presentation on their user stories. As they go through each user story, update the status accordingly (active, closed, blocked) and the amount of story points it actually took them (this is when you reference the amount of hours in their tasks). If a user story is not completed during the iteration, see section 'moving an unfinished user story to the next iteration'.
3. This is a time for individuals to celebrate and explain their work, get critiques, and feedback.

Moving an unfinished user story to the next iteration

If a story is incomplete at the end of an iteration, the team needs to figure out why and what the future steps are. Below are a list of questions that should be asked towards an unfinished story:

1. What were the main reasons to why the story didn't get finished? (too big of a task, lack of understanding, blockages, etc.)
2. Is there anything the team can help with to support the story?
3. Should it be moved into the next sprint (sometimes the user story becomes less of a priority)
   If it is decided that the story should continue into the next iteration, you will have to create another user story with the same title and transfer it to the next story.

Important Aspect of Sprint Reviews

1. Define Done: Make sure individuals understand the success criteria of 'done'
2. Celebrate the team: Sprint reviews are a great time to celebrate the team and everyone’s accomplishments during an iteration.

Tips:

• Try to keep sprint reviews casual. Team members gather around a desk for informal demos and describe the work they’ve done for that iteration. It’s a time to ask questions, try new features, and give feedback. Sharing in success is an important part of building an agile team.
• Try and keep the sprint to an hour.
• Do not let sprint reviews cross over into sprint retrospectives. The purpose of this meeting is to discuss the progress of tasks and completed work. Not what we can improve on in future iterations (that's for the retrospectives).
• Host a Sprint Review before a retrospective