Definition of the sprint review
The sprint review is held at the end of every sprint. This where the team demonstrate the next increment of the product to be delivered. The meeting is intentionally kept short and informal as the formalised part of the review will have already taken place. The way in which the meeting works best is to run the sprint review as a product demo where the new features that have been added during this iteration are presented to the audience.
Participants in the sprint review
The audience at the sprint review can be anybody who is interested in the latest developments to the product as well as the team. I suggest that all the team are present and will explain why in a short while.
Preparation for the sprint review
I often advise teams not to spend hours and hours preparing for the sprint review, however it is always good to make sure that it goes according to plan; so it’s really a question of doing enough prep for the meeting to make sure everything runs smoothly. I have sat in on some of the most embarrassing sprint reviews when senior management have been in attendance (isn’t it funny how it all goes wrong then); the team have had a most successful sprint and then they get bad PR when the overhead projector or some other technical aspect of the demo doesn’t work. So a tip, that seems so obvious so I ask myself why bother saying it, but turn up 10 minutes before the suggested start time and have a quick run through just to be certain of success.
Running the sprint review
So everyone is set up and you’re ready to go … I find that it is always useful to spent the first two minutes of the sprint review reminding (or informing because maybe everybody wasn’t aware) everybody of what the sprint goal was; which part of the goals you achieved and thus what will be demonstrated in the sprint review today. I often suggest that it is the Product Owner who gives this introduction, which is contrary to what Schwaber and Beedle suggest (they suggest the scrum master coordinates and conducts the review – Schwaber and Beedle, 2002, Agile Software Development with Scrum, Pearson education, p55) I’m happy to explain my reasoning behind this slight twist if anyone is interested. This nicely sets the scene and give a professional feel about the sprint review. Informal shouldn’t translate as unprofessional.
I always suggest that the Product Owner requests that if anyone has any questions to wait until the end of the demo. If necessary the team can rerun the demo in order to address any key points or questions raised. Of course this is optional and it may be easier for the teams to answer questions as they go, because there might be a lot to set up in order to rerun the demo; the Product Owner should explicitly state that preference at the start of the meeting. This is because often visitors might feel that it is being rude to interrupt the flow, and sometimes it is, but if the rules and boundaries are set at the start of the meeting then usually all will fall into place.
So once the scene has been set the Product Owner can hand over to the team for the demo.
It is important to note that we only cover what has been completed and has been agreed by the Product Owner to have met the required quality standard for the product. Anything that hasn’t been completed or “signed off” is not demonstrated. Which leads me nicely onto the real purpose of the sprint review.
The real purpose of the sprint review …
I see that there are two reasons for the sprint review. Firstly it offers the attendees the chance to understand and see for themselves the progress that has been made on the product. It might be necessary for the Product Owner to discuss where this fits into the overall scope of the product delivery in the introduction at the start of the meeting.
Secondly the sprint review offers the team a chance to bring closure to their work for the duration of the sprint. The items or features that are demonstrated are considered to be closed and thus any outstanding requirements or other associated documentation is considered to also be closed. This gives the team an opportunity to celebrate their success on meeting their goals and it is an opportunity for any senior management present to recognise and affirm the efforts of the team. This is why I said earlier that it is important for all team members to be present; everyone needs to feel that sense of closure and completeness for the work carried out in the previous iteration. Equally so, everyone deserves to share in the recognition of the work done to date.
What a sprint review is not …
- It is not a meeting designed to critise or for the team to take further actions for improvement to the product. It should be noted that this meeting is an informational meeting that raises awareness of the goals achieved thus far These are channelled through the product owner in the subsequent requirements gathering phase. Therefore it is not a Go – No-Go meeting. If the product is not considered fit for purpose before the review then my advise is to cancel the sprint review; the product owner can inform the necessary stakeholders as to why the product was considered to not meet the teams definition of done.
- It is not death by PowerPoint. I don’t like to be too directive on this point because PowerPoint does have its place; but the main focus should be on the demoing the product itself. This is not always possible and some other means of demonstrating progress can be creatively considered without the use of PowerPoint.
- It is not a document review meeting. Documents are often a necessary output from the product development process. If a document has been created it should be quality assured before the meeting and the smallest of introductions to identify where the document is stored and that it has been formally signed off according to the previously agreed definition of done.
Do you have any other tips for my other readers?
If you have any tips on how to run a successful sprint review then please submit them in the comment box below. I will also give a link back to your site in return. Thanks.