“I don’t need to check-in every Sprint Review; just send me a report!”
Stakeholders are busy people. Their day-to-day job is demanding and they are required to attend a lot of meetings, make decisions, manage multiple projects. They occasionally do not have a lot of interest in the software that gets built, as long as it does what it says on the tin. In a similar fashion with the Product Owners, they are used to get involved at the beginning and the end of a project and unsurprisingly they try to protect their time and eliminate any meetings they do not seem essential.
What stakeholders do not necessarily appreciate is that Sprint Reviews are for the benefit of the team; it is not for them to find what the team is up to, but for the team to find what the stakeholders actually want. You need to get them to understand that in the lack of detailed specs, this is the opportunity to inspect the product and adapt it accordingly. This is when they can request any changes and additions, so if they do not turn up they do not get a say!
Oftentimes the reviews fall into a few pitfalls:
• they are too long: in a two-hour review there is 20 minutes of value so their time is wasted,
• they are too technical: low level implementation details are being discussed,
• there is nothing to see: the stakeholders only want to review the full workflow and not the incremental pieces as they are developed each sprint.
Adjusting the structure of a Sprint Review to be focusing on the product is key to engage the stakeholder participation. It makes it easier for everyone to align their goals and visions for the project and continue to deliver a cohesive product.