Sprint Review is the scrum event that happens at the end of the Sprint, before Sprint Retrospective. This is probably also the most neglected scrum event.
Purpose: Inspect the Product Increment and Adapt Product Backlog.
Time-Box: 4 Hours for 1 Month Sprint, shorter duration for shorter sprint
Who: Entire Scrum team (Development Team, Product Owner, Scrum Master) and Other Stakeholders invited by Product Owner.
Role of Scrum Master: To make sure that the event takes place and attendees understand the purpose of the event. Her role is also to coach attendees to keep this event within the time-box.
Role of Product Owner: Sprint Review is an opportunity for a Product Owner to validate her assumptions around changes to the market place, new opportunities, potential customers, competition, etc., that can help her in making changes to the product backlog. Product Owner should also use this event to reinforce the product vision.
Myth 1: Sprint Review is a Demo/Show & Tell session.
Truth: Simply demo or show & tell is not the sole purpose of the Sprint Review. It is also not a session where stakeholders will scrutinise the team’s work. It is larger than that. It is an opportunity for the Product Owner & stakeholders to shape the future direction of the product. It is a session where the entire Scrum team and Stakeholders collaborate on: What was done during Sprint & What next things could be done to optimise the product value.
Myth 2: Product Owner provides sign-offs for functionalities in the Sprint Review?
“Product Owner must be available for the team, as and when needed”- Scrum Guide.
I worked with a client where culture was that the Product Owner will provide sign-offs during Sprint Review. I observed in some Sprint Reviews that the Product Owner was not happy with the increment produced and rejected functionalities. These are bad signs for organisations. This calls out an issue that the Product Owner was not working with the team during Sprint. One of the main responses to this kind of issue is, ‘Product Owner is too busy’. This also happens when proxy Product Owners are used.
Remember, Scrum follows emergent design principles where teams need to make many decisions within Sprints. If Product Owners are not available to help teams in making these decisions, then he/she may get some unwanted surprises. This will lead to rework which generally is demoralising for the team.
Few Practical Tips To Improve Sprint Review
Tip 1. Use a predefined agenda to cover the entire purpose of the Sprint Review:
For reference, I follow the below agenda that I find very useful.
Note: Text in italic are the roles accountable for respective activities.
1. What is Done/Not Done: Sprint Review starts with Product Owner giving a summary of what was ‘Done’ during the Sprint and what was ‘Not Done’ that has moved back into Product Backlog.
It is advisable that the current Definition of Done is highly visible to provide transparency.
2. How did the Sprint Go- Successes/Issues: In this step, the Development Team shares what issues they came across during the Sprint and also how they did overcome these. It is also good practice to discuss some successes that the team achieved. As a Scrum Master, I like this step because sometimes stakeholders suggest better ways to overcome issues. Also, this step provides ideas to other teams via stakeholders. This is also a nice step to discuss impediments that can’t be removed by the Scrum Team.
Stakeholders play an important role in spreading ideas as they generally are not limited to one team.
3. Demo & Feedback: The development team demonstrates what was ‘Done’. This should not be just a slide show. It should be an interactive activity where stakeholders ask questions about functionalities and also provide feedback. This step also provides very good feedback to the Product Owner whether her assumptions were right or wrong.
4. Current State of the Product Backlog: Product Owner presents the current state of the backlog. This will also have items ‘Not Done’ in the Sprint that is going to be completed. Based on the feedback received from stakeholders new opportunities may be identified, discussed as a group and later may be added to the Product Backlog.
5. What to Do Next- Everyone including the entire Scrum Team and Stakeholders will collaborate on what should be done next based on the learning from the previous sprints, changes to market place & new opportunities/risks/issues.
6. Adapt Product Backlog: The previous step will give enough knowledge to the Product Owner which she can use to reorder the Product Backlog or add/delete items. This will become an input to the next Sprint Planning. The Product Owner may also decide to discuss the updated release plan based on changes to the Product Backlog.
Tip 2: Have more frequent Sprint Reviews if the product is very volatile.
If you are working in a very volatile environment e.g where market conditions or technologies are changing very rapidly, then teams should meet stakeholders more frequently to get feedback on whether they are building the right product. This can be done by reducing the Sprint length and reducing the time gap between two Sprint Reviews.
Tip 3: Ask Questions at The End
Asking a set of questions at the end of the sprint review can provide confirmations to the Scrum Team. You can combine these questions with the steps mentioned in Tip 1. A few of these questions are below but I would highly recommend the Scrum Team to identify their question list.
a. Are there any new requirements that emerged from this review? — this is to identify if new functionalities have emerged from the review.
b. Has Release Plan changed?
c. Has Our priority ordered changed?
d. Has the design changed?
e. Has our vision changed?
On a similar note, please review this article by providing one thing that you loved and one thing that you hated about this article. This will help me Inspect and Adapt which is very important for my path to reach Scrum Mastery. Be Agile and Keep Learning. Thanks