Even though technically Sprint Reviews signify the closure of the sprint, it is start to build trust and improve collaboration!!!
The end of the Sprint results in an exciting yet anxious dialog between the product owner and team members known as ‘Sprint Review’.
I would like to share some knowledge bytes gathered from my experience of conducting Sprint Reviews for a relatively new scrum team.
Simple Tips for a Successful Sprint Review :
Preparations Prior to the User Demo :
Decide the frequency of the user demo: The frequency of these meetings would depend upon the length of the sprint, complexity of the user stories and the dependencies between the items. In the cases where the Sprint is lasting up to a month, upon completion of the user story , the team can decide to have a mini review with the Product Owner or the team can hold reviews every month.
Decide the items to be demonstrated: This particularly holds well when there is more than one user story to review, the interdependent items could be clubbed together in a specific order which is meaningful to the customer.
Decide who would demonstrate the functionality: The team can elect their representative for the demo. User demo provides a good platform to hone one’s presentation skills and build relationship with the business. Every individual in the development team should leverage this opportunity and lead this activity.
For every user story, analyze the background work to be done such as
- Creating the test data
- Gathering sufficient information around the business value behind the user story
- Any challenges encountered during the implementation
Decide the audience : In a global environment where teams are split ensure that the primary stakeholders for the user story are available for the demo. Though sounds a bit obvious, absence of the correct audience may take the requirement to a different direction as the other section of the audience might not have the same understanding of the item. Wherever possible have a face to face conversation between the users to capture their maximum attention.
During User Demo
It is very important that the scrum team and stakeholders view this as an opportunity to mold and shape the product.
The Scrum Master can start the demo by a short introduction of the team, welcoming the audience, reviewing the purpose, agenda and time boxes for this meeting. Minutes Of Meeting can be jotted down by the Scrum master.
Set The context: Setting the expectations of the attendees is critical for a smooth demo. The scrum master needs to ensure that the meeting is conducted in the logical format, the product owner and the stake holder are aware of the items being demonstrated with their “Done” criteria.
Connect To The Users: One of the vital factors to keep the audience engaged is to ‘Speak their language’ .The development team should focus on the benefits / value of the functionality demonstrated, in users perspective instead of showing workable software. Using technical jargons, database table names, explaining the code or too detailed description of any technical hurdles encountered during the implementation should be avoided. Merely demonstrating the functionality from technology perspective would not be as effective as relating the screens to the business actions.
Be Aware Of The Time: ‘Time Box’ is the key – Respecting everybody’s time. Scrum master should work as a ‘Timer’ to ensure that the meeting is not stretched long for unnecessary reasons. Practical ways in case of overrunning could be asking the audience if they are comfortable to continue or scheduling another session in the near future (most likely the same week)
Keep Everyone Focused : Get the stakeholders and the product owner to have ‘Hands On’ the functionality. For eg : If your user stories targets to publish a report , then the live report publishing is intended to be shown instead of the screenshot of the report. This is how a Sprint review would differ from a user story walk through. Product Owner can then initiate discussions with the team and other attendees as needed regarding new ideas to add to the functionality.
Post User demo :
There could be several possible actions post the Sprint Review.
First, a simple ‘Yes it is!!!’ from the Product Owner can create a sense of achievement in the team and the team would gear up for the upcoming sprint.
Contradictory to this, the product owner might reject the tasks done by the team and add the task back to product backlog.
Thirdly new requirements might emerge from the discussions during the demo as the stake holders are directly viewing the functionality quite ahead of its release.
Thus A Sprint Review could be aptly described by the quote
Tell me and I’ll forget , show me and I’ll remember , involve me and I’ll understand !!!!