There are four basic Agile meetings conducted in the Scrum framework, i.e., sprint planning, daily stand-up sessions, sprint review, and sprint retrospective. "Sprint" is the essential element of Scrum-based project management. When sprints are done rightly, it results in timely and quality product deliveries and more satisfied stakeholders. The sprint review meeting has a key role in executing the project effectively. So, this article will talk specifically about the sprint review meeting and discuss in detail the best practices to have productive review meetings.
The sprint review meeting is conducted right after the completion of the sprint session, mostly on the last day of the sprint. In this meeting, the product owner demonstrates how many sprint goals the team was able to complete in the sprint. Moreover, the team explains all the user stories one by one that they have completed in the current sprint. They also show any newly created prototypes/products.
The main participants of the sprint review meeting include the product owner, scrum master, development team, and stakeholders. The stakeholders act as end users in the meeting and are the main listeners of the demonstration presented by the product owner and the team. When the team is demonstrating the work they completed, stakeholders can ask questions in between or afterward to clear their doubts.
The length of the sprint review meeting is usually between 1-2 hours, but some might even extend it to 3-4 hours. The main goals of a sprint review meeting are as follows:
To sum up, the sprint review meeting is the perfect place for the team members to showcase their efforts, get timely feedback from stakeholders, and set aims for the next sprint.
A sprint review meeting is a casual and informal meeting session. So, there are no strict standards to follow. However, the general steps involved in the sprint review meeting are as follows:
Overall, the above steps are the common ones that most Scrum teams follow in the sprint review meeting.
A sprint review meeting helps teams to have a regular and timely review of their progress and orient their efforts in the right direction. Some of the main benefits of a sprint review meeting are as follows:
In short, sprint review meetings are a great way of evaluating progress, getting feedback, and motivating the team towards the end goals. Moreover, these meetings also help in refining the sprint backlog so that more important items are rescheduled and completed first.
Now that we have developed a basic understanding of what a sprint review meeting is about, including its basic steps and benefits, it's time to discuss the best practices for a productive and more rewarding sprint review meeting. We will divide these best practices into three sections, i.e., prior to the meeting, during the meeting, and after the meeting. This way, it will be much easier to learn and implement those best practices.
Following are the best practices to adopt before the start of the meeting:
The very first practice is to have a clear view of the meeting objectives. What this means is that everyone who is going to join the meeting should know what the main goals and objectives of the meeting are. To clear that out, you can set up the objectives of the meetings and send them to the participants. The objectives can be something like reviewing and assessing completed work, getting feedback, and determining future adaptations.
After clarifying the objectives of the meeting, the next recommended practice is to set up the agenda of the meeting. It will help to keep everyone to remain confined within the agenda and not start discussions that are off-topic. Typically, the agenda can comprise of following elements:
This way, everyone will know beforehand how the meeting is going to proceed and can remain more focused throughout the session.
**Note: **The above two practices are not required to be followed in every sprint review meeting. They suit well during the initial 1-2 review meetings so that stakeholders and the team get familiar with the process. Afterward, the team can skip these two practices in future meetings.
It is recommended that sprint review meetings are conducted on-premises because it results in better interaction among the team members and the stakeholders. But the meeting can also be conducted remotely, just like a team can do product backlog estimation remotely through Async Poker or other remote-based estimation techniques.
Let's say that some key stakeholders are unable to join the meeting on-premises or some team members are working remotely. In such cases, the sprint review meeting should not be delayed and must be conducted remotely via a video link session. Therefore, this should also be finalized beforehand so that the right measures are taken timely.
Once everyone has joined the meeting session, the following are the best practices to adopt during the meeting:
When a team says it has completed a user story, then it either means that it has been tested and sent to production or it still requires testing. So, there should be a clear definition of "done" so that there is no confusion for other team members and the stakeholders. This way, when the team says that a user story is finished, the stakeholders will know exactly what the team intends to explain.
Sprint review meetings are causal and informal meeting sessions, just like a get-together of friends once a month. So, creating presentations is a big no in review meetings. However, the team should present the working version of the product/feature that they have developed in the current sprint. Moreover, the tone should be conversational, encouraging a more friendly discussion and welcoming positive/negative feedback.
The purpose of sprint review meetings is to demonstrate the work done in the current sprint, highlight the challenges faced, and plan future sprints accordingly. Since the meeting also involves key stakeholders, some teams are afraid to tell if they didn't manage to meet the objectives of the current sprint. But that's totally wrong. The sprint review meeting encourages the team members to be open about what challenges they are facing. There are always chances that some sprint goals might not be achieved in a single attempt. So, they can discuss them, tell the reasons, and might even get more support from stakeholders that can uplift their morale.
Since a sprint review meeting is an informal conversation meeting, so everyone's contribution is highly recommended. The demonstration should not be restricted to the product owner, scrum master, or team leaders. In fact, members who played key roles in completing the user stories should present those stories. This gives members a chance of getting appreciation for their work and also improves their communication skills.
The length of the sprint review meeting should be as short as it could be. Normally, the length of the meeting is linked to the length of the sprint. If a sprint lasted for 4 weeks, then the meeting length should not be longer than 4 hours. Similarly, if a sprint lasted for just 1 week, then the length should be restricted to just 1 hour. On average, the length of the review meeting is 1-2 hours. It is mainly the duty of the product owner to make sure that the length of the meeting remains short.
A sprint review meeting is a practice to get constructive feedback from stakeholders, not strict judgment. The environment should be such that it encourages positivity. The members should not be afraid of being judged or blamed. Stakeholders should orient their wordings and doubts such that they don't sound judgmental. They should act as individuals who are trying to help, so members can be more expressive to them. All this will trigger better conversation and quality deliveries.
Teams should keep end-users in their mind throughout the review meeting. If they focus on the interest of stakeholders during the meeting, then the product will be satisfying stakeholders, not the end-users. The best practice is that think of stakeholders as end-users and asks them to also assume themselves as the end-users. This way, both the team and stakeholders are focusing on the end-user, which will help in pinpointing issues that were somehow skipped and also lead to more quality user-centric products.
After the meeting session is completed, there are still some practices that can help out the team positively. So, a few best practices after the meeting are as follows:
Meeting notes are a great way to make sure that everyone is on the same page. It lists what decisions are made in the meeting and what main actions are taken. It also helps to make sure that everyone is committed to achieving the end goals of the project.
After concluding the review meeting, the team should sit for a few moments to relax and enjoy the work they have accomplished in the current sprint. Some fun discussions or appreciating the hard work of key members can greatly help in increasing the morale of the team for future sprints.
Stakeholders' satisfaction is very important for the development team. So, they must not be left in the dark after the meeting. Instead, the team can keep in touch with stakeholders to get their regular feedback and have better, friendly relations with them.
Sprint review meetings are an essential element of Scrum-based project management. As mentioned above, the goal of the sprint review session should be to present the accomplished work, gather feedback, and set up directions for the next sprints. But a team can easily make it an ineffective and time wastage session if done wrongly. The above-discussed best practices can help you and the team to have a productive and rewarding sprint review session. So, practice them and find out more by yourself and elevate the efficiency of your sprint review meetings.
