Best Practices for Productive Sprint Review MeetingThe goal of the sprint review meeting is to demonstrate the accomplished work in the current sprint, get feedback, and set directions for the next sprints. Here are the best practices to adopt to turn a review meeting into a productive session.
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.
Sprint Review Meeting – A Brief Overview
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:
- Present what the team accomplished in the sprint.
- Get feedback from the stakeholders.
- Help members orient their efforts towards main project goals.
- Discuss what they are going to do in the next sprint.
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.
Steps to Conduct a Sprint Review Meeting
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:
- Everyone joins the meeting session.
- The product owner provides a summary of what sprint goals are achieved and what are left out.
- The development team explains the user stories they completed one by one, including what problems they faced, the solutions they adopted to solve those problems, and similar other details.
- The stakeholders ask questions to clarify their doubts.
- The product owner provides a summary of the current position of the backlog and might also update the estimated product completion time.
- The team gathers all the new information and the response of stakeholders to decide what they should aim for in the next sprint.
Overall, the above steps are the common ones that most Scrum teams follow in the sprint review meeting.
Benefits of a 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:
- It helps the team to see their work quality and progress status.
- Stakeholders remain engaged and get their feedback heard continuously.
- Improves the quality of the product.
- Keeps the project progress transparent.
- Helps the team in developing friendly relations with the stakeholders.
- Helps in updating the sprint backlog and reprioritizing the user stories if required.
- Appreciation by stakeholders encourages more productivity.
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.
Best Practices for Productive Sprint Review Meetings
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.
Best Practices Prior to the Meeting
Following are the best practices to adopt before the start of the meeting:
1. Clear View of the Meeting Objectives
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.
2. Set up the Agenda of the Meeting
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:
- Greetings to the members
- A comprehensive review of the current sprint progress
- Explanation of the completed work
- Feedback from stakeholders
- Next sprint discussion
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.
3. Finalize On-Premises or Remote Meeting Session
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.
Best Practices During the Meeting
Once everyone has joined the meeting session, the following are the best practices to adopt during the meeting:
1. Definition of "Done"
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.
2. Keep it Causal and Informal
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.
3. Be Honest
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.
4. Everyone Should Contribute
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.
5. Keep the Meeting Short
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.
6. Avoid giving Judgment
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.
7. Focus on the End-User
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.
Best Practices After the Meeting
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:
1. Meeting Notes
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.
2. Celebrate Success
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.
3. Keep in Touch with Stakeholders
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.