Do you make sure Sprint Reviews are "tick and flick"?
Last updated by Tiago Araújo [SSW] 4 months ago.See historyIt's essential to keep Sprint Reviews as efficient as possible. Unfortunately, Sprint Reviews can be boring because they involve developers slowly demoing each Product Backlog Item (PBI) to the Product Owner. Better communication with the Product Owner can transform this into a swift "tick and flick experience", leading to more efficient reviews.
Get PBIs into a "tick and flick" state
Getting a PBI into a "tick and flick" state involves ensuring that the Product Owner has been shown the PBI, reviewed the changes and provided feedback. It can be a physical demo, or it can be a 'Done Video'.
If the developer has shown the Product Owner the PBI prior to the Sprint Review, then in the Sprint Review, when the PBI is reached the developer can remind the Product Owner it's been reviewed and ask if they are happy to move on.
Developer: This PBI is about making the new customer contact form. Let me show you what I've done:
🖥️ Developer Demos the change
Developer: Any questions?
Figure: OK example - Showing the Product Owner the PBI for the first time during the Sprint Review
Developer: This is the PBI I showed you on Monday about creating the new customer contact form. Are you happy to move onto the next one?
Figure: Good example - Confirming that the PBI has already been reviewed so you can move on
Make a Sprint Review a "tick and flick" experience
To make a Sprint Review "tick and flick", you want as many PBIs as possible to be in a "tick and flick" state. Every project is different, so the process will differ depending on the project and the Product Owner's preferences. However, the general idea is that you communicate the completion of a PBI to the Product Owner and give them a visual indication of what was changed.
Here are some tips that help improve communication with the Product Owner during a Sprint to help get PBIs ready for the Sprint Review:
- Use @mentions in a PBI - Utilize @ mentions in a PBI to alert the Product Owner and other relevant team members about any updates, questions, or issues related to a PBI. Using @mentions ensures that everyone stays informed, and any concerns are addressed before the Sprint Review
- Document decisions and discoveries - While working on the PBI make comments about any decisions or discoveries, that way when a Product Owner reviews the PBI they will be able to see the context of everything that happened
- Close the PBI with context - By adding relevant information to close off the PBI, the Product Owner can quickly get a handle on the status of the PBI
- Send 'Done' emails - Use 'Done' emails to notify the Product Owner when a PBI has been completed. This includes a brief description of the work done, links to relevant documentation, and any other essential information. Sending these emails helps keep the Product Owner informed and allows them to prepare for the Sprint Review
- Send 'Done Videos' - When appropriate, make a habit of including a short video demonstrating the completion of a PBI in your done email. This will give the Product Owner an opportunity to review the work before the Sprint Review meeting, saving time and ensuring any issues are addressed beforehand
- Call the Product Owner to run through what's been done in the PBI
By incorporating these tips into your team's workflow you can keep the Product Owner informed and subsequently make Sprint Reviews "tick and flick".
Common mistakes in Sprint Reviews
Here's a video highlighting common mistakes that can slow down Sprint Reviews:
Video: Run a smooth Sprint Review | Jeoffrey Fischer | SSW Rules (4 min)