Do you make sure Sprint Reviews are "tick and flick"?

It'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 your 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

How do you make a Sprint Review a "tick and flick experience"?

To make a Sprint Review a "tick and flick experience" 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 the PBI into a "tick and flick state" and 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, and turning PBIs into a "tick and flick state" you can keep the Product Owner informed and subsequently make Sprint Reviews a "tick and flick experience".