What is a Sprint Review/Demo Meeting ?
- highly productive feedback loop that enhances your Scrum Team
- It makes the progress of the team transparent ( to management, stakeholders, to other teams and themselves)
- A chance to show what they have achieved and a forum to celebrate their accomplishments
- Tick of things which are done.
Why should the Sprint Demo be awesome??
- Touch Point with your customer – They remember this and most of the time determine how things are based on this interaction and the results of this discussion.
- Moreover, this is what the team worked hard for a complete sprint to achieve, this is “The Moment” to showcase your efforts and get feedback and improve on the product at hand.
Does/Dont’s for Sprint Demo :
- More than just a demo
- Ensure that you have invited the right stakeholders (involving the PO)
- There should be an agenda – Demo Script
- Demo Setup – Up and Running ( As agreed, consistent. Not demo apart from the demo environment)
- Environment – Bright lit and not boring and dark
- Energy is very important, the person giving the demo should be aware that he is demonstrating every body’s work in the team, the energy should reflect in the demo.
- Interesting and a bit informal ( depending on audience)
- Ensure that it is visible to all in the meeting
- Do it from a single machine/location.
- Be available ( not someone walking in after the demo starts).
- Keep your mobiles (silent),other sources of disturbances at bay
- Prepare for this Interaction (it should be “Great”) and “No surprises” – Pre-demo. Create Relevant test data, if the story has no visible UI provide relevant tests. Don’t skip them.
- Time Box it 1-2 hour for a team of 4-5 professionals ( 2 Week Sprint)
- Have an introduction from the Product Owner on the Sprint Goals – on what to expect for the stakeholders
- Inform everyone: was the sprint a success, i.e., did the team meet their commitment to the sprint goal?
- Use your best communicators for the sprint demos.
- Welcome all feedback, make a note of the same ( any team member) and sent it back to the PO and stakeholders
- In presenting every story provide a business overview of the importance and a bit of background of each story = What Business Value it has, what problem is it solving, benefits and so on.
- Focus on the acceptance criterions of the Story – avoid exhaustive repetitions of scenarios and keep it interesting and what’s valuable.
- Not Done items are not demoed.
- Never cancel a demo. If the team has nothing to demo, then display the progress at the demo- but never cancel it. Cancel the demo sets a bad signal to the team that the demo’s are not important.
- Ask for suggestions/feedback on gaining more business value.
- Decide with the PO on how to work on the feedbacks and priority.
- PBI’s are not marked as “Done” before the Sprint Review
- The DoD contains the Quality Metrics (Code Metrics), Testability Parameters(Unit Tests and Functional Tests Report) and Practices(@Prowareness we use a 30 Agile Practices list and only showcase the ones which were really DONE) used – show them, no proof only adds to the customer imagination. Transparency does wonders to build trust with stakeholders and management. Incase your customer is non technical ( have no clue about quality, educate him about him – after all he may have to spend effort/money in managing the solution later on, its his right to know what quality did he sign up for)
- Always celebrate (cheer/champagne/or just a thank you) at the end of the demo with all the team members and other involved in making the sprint a success.
Looking for the right recipe for your team demo, try the following out ?
>>Create cross functional team/group of 4-5 people
>>How would you rate(1-5) the last demo you attended ?
>>What was the best demo you ever attended and what was special about the same ?
>> Create the perfect Demo recipe (share and discuss ideas across teams)
- Setup( Infrastructure and Environment)
- Execution of the Demo