During a project using agile management methodologies, you hold periodic sprint reviews — meetings to review and demonstrate the user stories that the development team completed during the sprint. The sprint review is open to anyone interested in reviewing the sprint's accomplishments. This means that all stakeholders get a chance to see progress on the product and provide feedback.
The sprint review meeting is valuable to the development team as it provides an opportunity for the team to show its work directly and get recognition from the stakeholders. The meeting contributes to development team morale, keeping the team motivated to try and produce ever increasing volumes of quality work. The sprint review even establishes a certain level of friendly comparative competition between scrum teams that keeps everyone focused.
The sprint review is Stage 6 in the Roadmap to Value, as shown:
Preparing for an agile sprint review
Preparation for an agile sprint review meeting should not take more than a few minutes at most. The sprint review focuses on demonstrating what the development team has done. Knowing the completed user stories and being ready to demonstrate those stories' functionality prepares you to confidently start the sprint review meeting.
Preparing for the sprint review meeting involves the product owner and the development team. The product owner needs to know which user stories the development team completed during the sprint. The development team needs to be ready to demonstrate completed, shippable functionality.
For the development team to demonstrate the product in the sprint review, it must be complete according to the definition of done:
As user stories are completed throughout the sprint, the product owner and development team should check that the product meets these standards. This continuous validation throughout the sprint reduces end-of-sprint risks and helps the scrum team spend as little time as possible preparing for the sprint review.
Tips for holding an agile sprint review
The sprint review usually takes place later in the day on the last day of the sprint, often a Friday. One of the rules of scrum is to spend no more than one hour in a sprint review meeting for every week of the sprint. Guidelines for your sprint review meeting:
No PowerPoint slides! Refer to the sprint backlog if you need to display a list of completed user stories.
The entire scrum team should participate in the meeting.
Anyone who is interested in the meeting may attend. The project stakeholders, the summer interns, and the CEO could all theoretically be in a sprint review.
The product owner introduces the release goal, the sprint goal, and the new capabilities included.
The development team demonstrates what it completed during the sprint. Typically, the development team showcases new features or architecture.
The demonstration should be on equipment as close as possible to the planned production environment. For example, if you are creating a mobile application, present the features on a smartphone — perhaps hooked up to a monitor — rather than a laptop.
The stakeholders can ask questions and provide feedback on the demonstrated product.
No non-disclosed rigged functionality, such as hard-coded values and other programming shortcuts that make the application look more mature than it currently is.
The product owner can lead a discussion about what is coming next based on the features just presented and new items that have been added to the product backlog during the current sprint.
By the time you get to the sprint review, the product owner has already seen the functionality for each of the user stories and has agreed that they're complete.