The Sprint Review is the ritual that comes when the Sprint has finished, and we do a demo of all the work done for the Product Owner (PO) and the stakeholders.

The idea of the Sprint Review meeting is not to become a distraction or a detour for the team but to be an informal and natural result of the Sprint. In order to improve the value and results of this meeting, here is a compiled list of tips, tricks, and steps to follow to have better Sprint Reviews.

Creating the right environment for a Sprint Review

• Set the stage: The Scrum Master should make sure that all the participants (Team, Product Owner, and invited stakeholders) know each other, and if there is someone who is not part of the team, that someone is briefly and correctly introduced.
• Communicate the Sprint Review agenda: I strongly recommend setting and sharing the Sprint Review agenda from the very beginning of the meeting, making it clear how long we estimate each phase is going to take.

Each phase should be addressed and have its corresponding time box. As the idea of the Sprint Review is to get feedback from the Product Owner and the organization, be sure to give them the time and space needed to get all the feedback needed.

• Explain what will be reviewed and what will NOT: It will help avoid potential comments –especially from the Product Owner or some particular stakeholders– regarding the lack of functionality. It will also save everyone’s time by avoiding feedback that the team does not really need.
• Prepare the PO and stakeholders for the demo: The team should present how the Sprint was: what went well, the issues they had to face and how they overcame them, and setting up the expectations for what will be shown next.

• Do the demo: This is the heart of this Scrum ritual. Although there is no exact definition of who should be the one presenting, some people say that the PO is a good choice. I think that any team member can be a good choice, but I suggest taking the following into account:
  • The entire team should be focused and available to answer any questions from the stakeholders.
  • The presenter should pay attention to potential deviations from stakeholder questions and must be focused principally on showing the functional path that leads to the acceptance criteria stated in the User Story.

• Space for discussion: One of the main objectives of the Sprint Review is to have feedback from the PO and discuss the User Stories that have been shown, focusing on both the things that can be improved and the new ideas for the future.

As the PO will not be part of the Retrospective Meeting –at least I do not advise you to do that unless it is carved in stone–, this is a good scenario to get his perspective and hear the team. This should be a small and facilitated space that adds value to all attendees.

This might be interesting: 5 ideas to improve your next Scrum Retrospective

Tips for a better and interesting Sprint Review

• Time Boxing: This is a Scrum essential. As in all other rituals, we have to allocate a fixed amount of time for this event. This is great for productivity, as it incentivizes the team members to complete the work within the given time.

It also helps as a motivation since the team knows when it ends. Finally, who likes endless meetings? An ideal Sprint Review can go from one hour (small teams and short Sprints) to 4 hours (bigger teams and longer Sprints). If you need more time, you should review how your Scrum process and team/stakeholder dynamics are working.

• Keep it informal, but not THAT informal: Dedicate some time to prepare the meeting. It should be no more than 2 hours in order to keep it Lean.

Find the sweet spot. I know that the balance between getting the best result with the smallest possible effort is a hard task, but I strongly recommend putting some time into planning the Sprint Review. On several occasions, I have seen room for improvement in these specific items:

* Preparing the meeting room and communication especially when dealing with remote teams.

*  Preparing the development environment carefully. I notice that sometimes the presenter has to deal with unexpected workarounds or incurs excessive delays in showing the desired review results. A good and useful practice is to choose in advance an accurate data set to work on.

*  Checking the Definition of Done (DoD) of each Story –what we will show when we say it is done– and show each story considering this approach.

• Talk in the user language: The end-users –both the PO and the stakeholders– are a vital part of this meeting. Therefore, all the team should focus on speaking their language, making sure that they understand and avoiding technical slangs or terms that can be hard to understand.
• Team members should present their own User Stories: This is my special signature and is something that is not often done that adds a lot of value to the team. I like the idea that each member presents the User Stories they have worked on. This could imply some additional work, but I find that the benefits outweigh this extra effort. I can highlight the following advantages of this:

• All the team members acquire experience interacting with the end-user and talking with the public. This is something that always completes the developer profile in a positive way.
• Knowing in advance that every team member will present his/her User Stories, it will give each member the ownership of the task at hand from the very moment he/she started working on it.
• Everybody will feel empowered. This makes the team feel that their work counts and that it is important for the product. It also encourages the idea that they are an active part of what is being built. They face the users and show them their achievements.

Content related: Scrum meeting: how to succeed in a Sprint Retrospective

To sum up

The Sprint Review is an informal Scrum ritual, but adding a set agenda and following some particular tips –always focusing on the client– will transform your good Sprint Retrospectives into impressive ones.

Having a better Sprint Review will depend on several factors, but there is great importance on the team and Scrum Master teamwork. Create the right environment for the review to set the stakeholders’ expectations, and plan in advance –taking just the right and minimal amount of time– which User Stories will be showed.

All the listed tips and tricks will help you get better Sprint Reviews. Let’s put them into practice!

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.