What Is Sprint Review Meeting and How To Hold Fantastic Ones
Sprint Review meeting is carried out once the Sprint has been done. It is meant to inspect the Increment and adapt the Product Backlog if necessary. When the Sprint Review meeting is taking place, the Scrum team and stakeholders evaluate what has been done during the Sprint.
The review serves for sharing information, this is not a status meeting. It is solely held to get some feedback as well as ensure that there is collaboration.
During a Scrum, a regular sprint review meeting is scheduled to demo and determine the product usability. Teams are expected to deliver a shippable product during each increment or Sprint.
To ensure their success, a sprint review meeting is held at the end of each sprint. During the review, the Scrum team shows the stakeholders what they have accomplished by demonstrating the newly designed features.
Sprint review meetings are deliberately informal. Programs like PowerPoint are forbidden and a preparation time limit of 2 hours maximum is set. These meetings are not, nor should they be viewed as a distraction or major detour for the team. Instead, they should be a natural transition and result of the sprint session.
Typically, the Scrum Master, members of the management team, the product owner, customers, developers from other projects, and the Scrum team participate in the sprint review meeting.
A goal for the software is set in the sprint planning meeting. Achieving this sprint goal is very important. To ensure this has been done, the delivered project is assessed and compared to the goal during the sprint review. Each product backlog is also brought into the review to ensure that the goal has been met.
Sprint Review Meeting
In a Sprint Review meeting, the Scrum Team and stakeholders discuss the work done during the Sprint. After assessing the work done along with changes made to the Product Backlog, the group collaborates on what steps should be taken next to optimize the value of the software. These meetings are always intentionally informal to keep the group focused on encouraging feedback and collaboration.
For month-long Sprints, review meetings should last a maximum of four hours; referred to as time-boxed sessions. If the sprint sessions are shorter in duration, the review meetings will also be shorter.
The Scrum Master is responsible for scheduling the meeting and informing everyone attending of the purpose of the review. The Scrum Master is also responsible for ensuring the meeting stays within the time-box.
The sprint review meeting should include the following:
- Attendance and participation of the Scrum Team, product owner, and invited key stakeholders.
- The Product Owner should report the items in the Product Backlog; what backlog items have been done and what have not.
- The development team discusses what went well and the problems they experienced. They should also inform the group what they did to resolve the problems.
- The development team demonstrates their completed work while answering questions about their increment.
- The product owner leads the discussion on the Product Backlog as it currently stands. They set projected completion dates based on the progress of the Sprint session.
- To give valuable input to the Sprint planning, the entire group establishes the next steps during the Sprint review meeting.
- This is a time to review potential changes in the marketplace, the valuation of the project and what areas are considering to be the most valuable. The next steps should also be outlined.
- Review the timeline, budget, potential capabilities, and marketplace to determine the next anticipated product release.
By the end of the Sprint Review Meeting, revisions should be made to the Product Backlog to better define probable backlog items for the next Sprint session. The Product Backlog can be adjusted completely to introduce new opportunities.
Focus on the End-User
Companies can be reluctant to involve end-users for several reasons: some fear of scope creeping, others believe they are not allowed to ask the end-users to get involved while some do not know who their end-user is. End users are a vital part of the session. Never find an excuse not to involve them!
Involve the Product Owner
Too often, many companies organize their sprint reviews as a team presentation for the product owner to grade or judge their work. This format is complete nonsense! Sprint Reviews are not legal inquisitions or courts, they are informal meeting designed to gain the customer’s feedback.
Rather than presenting their data to a judge-like product owner, teams should collaborate with the product owner to review each completed story.
At the beginning of the sprint review, the product owner should stand first to welcome everyone and provide a project overview. The owner can then discuss the goals of the Sprint: what was achieved and what goals were not.
It’s also a good time to talk about the quality level of the product, the software’s release, and product burndown. The owner can pinpoint what the reviewers should be looking for and explain to the team how to give their feedback.
After they finish their introductory statements, the product owner can turn the meeting over to the Scrum team for a demonstration of the software’s functional abilities.
Understand Group Dynamics
The group dynamics are altered significantly when the focus of the meeting changes from alone product owner to a group collaboration that includes the Scrum team, stakeholders, and the end-users.
When the product owner becomes part of the presenting team, the above roles change. Here’s a look at how each group is affected.
The Product Owner’s role changes to that of the real owner of the product. As a key member of the team, the owner becomes more responsible and accountable for the product. They are answerable for decision-making and for presenting the results to the end-users and stakeholders. He stands up and presents the product increment and gives insight into the state of the project.
By changing the role, the owner understands that he/she becomes more disciplined in maintaining the product design, release burndowns, and setting a level of quality for the work.
Another noticeable byproduct of this change is that discrepancies can be seen immediately. If the owner’s perceived reviews of the end users’ needs do not match the actual needs, it will become immediately noticeable.
The Scrum Team has a greater sense of pride and accomplishment and is better positioned to demonstrate their work to the group. They are allowed time to the end-user, and, in the best-case scenario, meet with the end-users face-to-face time.
Knowing the end-user is the best way to develop quality software that will offer the highest value to the end-user. By learning to accept feedback at each sprint session, the team gains more appreciation for the product owners and customers.
The team will also feel less like they are being judged or graded by the product owner. They will come away from the meeting feeling more energized and motivated towards the next sprint.
When executives and stakeholders are part of the review meeting, they can see the teamwork while participating in a real review of the work done and actions taken. Additionally, the end-users can personally inform the executives/stakeholders of their needs.
Most importantly, they learn to act appropriately. The dynamics of these meetings are significantly different when customers are part of the session.
When end-users are present, executives and stakeholders spend less time bickering and criticizing others. Instead, everyone is on their best behaviour, ensuring the review is more motivated and productive.
Without question, the end-users are the stars of the review meetings because they spend valuable face-to-face time with the software developers. They spend so much time with the developing group, the end-users feel a sense of belonging.
Because they spend so much time and involvement in the development of the project, the users become the biggest company supporters. This acquired knowledge is valuable in reducing in a flood of support calls that are common after a release.
The Scrum Master facilitates the Sprint Review Meeting. This person establishes an environment among all members so that great accomplishments and goal achievements can happen. To make it happen, the Scrum Master must make sure the right people are at the meeting. He/she must also ensure the right room and supplies are readily available.
Other smaller details like ordering food and drinks are also the responsibility of the Scrum Master. While this may seem unimportant to some, food is the fuel that teams need to continue their hard work during the meetings. Personally, I have had many great conversations with teams while eating together.
One thing to keep in mind, this is not the Scrum Master’s show – they are not the star. The Scrum Master is there to support the team. They also welcome the end-users and make sure they are included in the team, have the chance to be heard, and are behind the scenes.
To master the art of feedback, you must first create an environment that allows open feedback to happen. Involving the end-users in the Sprint Review Meetings can be scary, but remember: hearing the feedback early gives you time to make the needed adjustments.
Waiting until the end to find discover you went down the wrong path is a waste of precious time and resources. So, if you’re still afraid of scope creep, let it go. During the review, the Product Owner will first decide what trade-offs will make after each Sprint Review.
You can use this opportunity to find out more about what the end-users need and do not need; this helps reduce and eliminate overproduction of some features that will never be used.
By focusing on the end-user, and creating energy and excitement, you will create a Sprint Review Meeting that customers will want to attend. It’s easy to do; simply set up a review that offers direct value for the end-user. Once that is done, just sit back, and listen. You will be surprised what you learn.