As this is my first post on Agile Scrum, I want to start by saying how much I believe in the methodology and think it can help a team thrive.

Within the Scrum cycle you have Sprints (normally 2 – 4 weeks), and at the end of each there is a Sprint Review. This review allows the Scrum team to demonstrate what has been achieved during the last Sprint, and assess the teams progress against the Sprint goals. I have detailed below some things I believe can lead to a great Sprint Review.

First let me share what I think makes a great review. The two key things for me are feedback and transparency. The chance for positive feedback can be a motivator for the team, and feedback on the work completed will lead to a better solution. The review is also a great opportunity for the team to highlight any impediments and be completely transparent about what has been achieved. In order to get these benefits the review must be engaging, and have the right audience.

Invites / Audience

You will often hear that the review should be open to anyone with a stake in the project, and I tend to agree, but this is an extremely vague statement. I believe inviting an entire distribution list can put possible attendees off, making them think it must not be important to them, or someone else will attend.

Targeting individuals who have the biggest stake in the project and providing details on what will be reviewed can often increase attendance, even when you are reducing the invitation list. This is something that can be driven by the Product Owner, who has a better knowledge of customers / other areas of the business that would benefit.

Demonstration

These sessions are informal and rightly so, but informal does not have to mean unprepared. Mountain Goat states that ‘a sprint review meeting should not become a distraction‘, and eventually this is true, but when a team is newly formed preparation is key.

Writing demonstration steps, preparing test data, and even doing a run through is not excessive. This will lead to a better flow in review and ultimately result in better feedback.

Make it a Story

Following on from preparation, each demonstration should be told as a story rather than tasks completed during a sprint. For example if during the sprint you built a reset password feature, you would not want to present each development task separately. Having tasks such as; issue reset link, build password change, implement security checks, etc. This would make the review difficult to follow and probably be too technical for the audience.

Instead tell it as a story. I use the following structure when demonstrating a story / bug:

• Introduce the ticket: Explain the purpose of the story or the symptoms of a bug, this should always be from the users perspective.
• Demonstrate the change: When demonstrating the change try not to get into the technical detail, explain it from the point of view of the user and not developer / tester.
• It’s a story: Changes in the same area should be grouped and treated like a story, try and get stories to follow on from one another.