Conducting a Sprint Review

Once the team has completed the development phase of the sprint, the next step is to conduct a Sprint Review.

What is a Sprint Review?

A Sprint Review is a demonstration of the new functionality to all project stakeholders. The meeting serves to alert stakeholders of the progress made in the sprint and to set the stage for the next sprint.

Who attends the Sprint Review?

The Sprint Review meeting is attended by the project stakeholders. These stakeholders include the:

  • Product Owner
  • Project Team
  • ScrumMaster
  • Executive Sponsors (if applicable)
  • Customers (if applicable)

Why conduct a Sprint Review?

The Sprint Review meeting is important because it allows you to follow one of the core principles of scrum – continuous feedback and iterative improvement. The Sprint Review meeting allows you to receive feedback on the functionality that was just developed. This helps you to ensure that you are on the correct path, or to help you get back on the right path if you were heading in the wrong direction.

What is the structure of the meeting?

A Sprint Review meeting is informal in nature. Teams should aim to not use a PowerPoint presentation. The meeting is designed to stimulate conversation and PowerPoint slide decks often serve to stifle dialogue. Instead, the team should converse with the stakeholders in an attempt to engage.

How long should the meeting last?

The meeting duration should correspond to the amount of functionality that was developed. In general, these meetings should not exceed an hour in length, and they often are as short as 10 minutes.

Who demos the functionality?

Do not feel obliged to have the ScrumMaster present the functionality every meeting. Anyone on the team is encouraged to give the demonstration.

One Reply to “Conducting a Sprint Review”

  1. Great post, i really enjoyed it.

    At my work we’ve done basically the same thing as you describe for our Sprint Demo/Review. Usually the first sprint we don’t have anyone attending except the PO. (we do 3-4 sprint releases… because we’re a bank and the technology integrates slowly so usually it’s ‘potentially shippable’ but not ‘shippable’).

    Anyhow, I think I’ve read in the scrum books (schwaber etc) that you shouldn’t even have a ‘scripted’ demo run by the team, but instead have the software on demo machines for the PO and stakeholders to just use it. I’ve never really tried to let the stakeholders run the software but we definitely let them just talk and ask questions. It almost always uncovers new requirements (for the backlog).

    It’s to the point now where I crave the feedback so much i wouldn’t dream of not having a sprint demo for fear of building the wrong thing for more than 1 sprint at a time.

Leave a Reply

Your email address will not be published. Required fields are marked *