The Sprint Review's focus is on the increment of working software that has just been built and how successful the Sprint has been in moving the product's progress forward.
This is how you set it up:
What you'll need: A large screen to demonstrate your working software, the User Stories you've completed, the User Stories you didn't complete, the Sprint Goal, index cards, sharpies, and post-it notes
Setup: A large table that the whole team can fit comfortably around with a view of the screen
Attendees: The Scrum team and stakeholders
Time-box: 4 hours for 1-month Sprints; for shorter Sprints, the event is usually shorter
The central focus of the Sprint Review is for your team to demonstrate the working software they've built as part of the Sprint. They should decide upfront which member of the Development Team is going to show the working software. You may decide that it will be a group effort, in which case, you should decide which team members will show which of the completed User Stories.
The basic flow for the Sprint Review should be along the following lines:
- The team member who is demonstrating the first complete story reads out the story card, including the acceptance criteria.
- They then demonstrate the software and explain how it meets the acceptance criteria.
- They then ask for any questions or observations.
- The team member who is demonstrating the next complete User Story takes that story card and repeats the process.
The Sprint Review is an opportunity for you to engage your stakeholder group and gather feedback on whether the product is moving in the right direction. Of course, your Scrum Master and Product Owner should be able to recognize that this is the first Sprint and that the software you've delivered won't necessarily show a complete set of features.
Once all complete stories are demonstrated, the Sprint Goal should be read out by the Product Owner, and the team should discuss and review whether they've achieved all, part, or any of it.
The final part of the Sprint Review is to open the room to any questions or observations. For example, the invited stakeholders may be interested to hear what the team has planned next. They may also be keen to offer feedback about the direction the team is moving in, or even suggest changes or a new direction. This feedback is likely to be incorporated into existing User Stories or may even create new User Stories.
The worst case scenario during a Sprint Review is that there is no working software to demonstrate, which can happen if a team hasn't completed any User Stories or if the working software is hit with technical difficulties. If this happens, the team should move directly to the Sprint Retrospective.