Scrum Sprint Review Meetings

The Scrum Guide defines Scrum Sprint Review Meetings:

The focus of our review meetings are:

• Demo or die
• Sync with the stakeholders
• Collaborate
• Update backlog
• Looking forward

Demo or Die

The Scrum Sprint Review Meetings are informal meetings where the developers can come and show their steel. I like to emphasise that the product belongs to them. Although the Product Owner has the final say and gives direction to the project, they take the responsibility of actually building the product and they should be excited about the results produced.

Hence the concept of Demo or Die. If the team is excited and proud of their product, the stakeholders will experience the energy and get excited as well. I would suggest that the excitement surrounding the project is almost as important as the deliverable increment itself. If the stakeholders lose their interest in the product, it will eventually die.

Who should attend

• The scrum team
  • Scrum Master
  • Product Owner
  • Development team
• Internal stakeholders
  • Business owners
  • Executives
  • Managers
• Other internal teams
  • Sales
  • Marketing
  • Support
  • Legal
  • Compliance
  • Other development teams
• External stakeholders
  • External Customers
  • Anyone who can provide valuable feedback

Sync with the stakeholders

As can be seen in the previous section, a wide range of stakeholders can join the meeting. This can result in a very diverse and fun conversation. It is worth mentioning that the meeting is time boxed. The Scrum team should be properly prepared for this meeting. They need to be able to answer all questions raised by the stakeholders.

I recommend a time box of a maximum of 2 hours for the team to prepare for this meeting. The meeting should not take the form of a presentation (eg. powerpoint) but an informal conversation where collaboration is fostered. The Scrum team needs to check their ego at the door. One of the outcomes of the meeting is a revised backlog. The stakeholders bring a new perspective which can potentially lead to pivots. The Scrum team needs to be prepared for this.

Collaborate

This is where the waterfall mindset becomes a potential pitfall again. Teams and team members are conditioned to report to superiors. The mindset of being in ‘the same boat’ easily evade teams. If the Product owner or stakeholders are perceived as the DEV teams’ enemies or superiors and not team members, the battle is lost and the value of Scrum is seriously diminished.

The DEV team should be given the opportunity to lead the ‘demo’ section of the meeting and they should create opportunities for valuable inputs from the stakeholders while guiding them through the increment that was delivered in the previous sprint. This keeps the subject of  the collaboration on point.

Update the Backlog

During the meeting, it is the responsibility of the Product Owner to update the current product backlog. The business value of each of the new backlog items can be determined later. My experience is that, if the meeting is facilitated correctly, it can create the opportunity to brainstorm and divergently question the product. After this meeting, the product owner should have an idea of what a valuable backlog would be for the next sprint.

To quote the Scrum Guide:

The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.

Looking forward

According to the Scrum Guide:

The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date.

In the final part of the meeting, the product owner is given the opportunity to give the attendants an overview of the project.

The following are usually discussed with the team:

1. Project status and future projections
2. Release planning
3. Approach for the next sprint