Tips for an Effective Agile Sprint Review
The agile team works hard. Pushes out an update to the product. Now key stakeholders want to see all this work. But simply showing this work is not enough, gathering feedback and answer questions will provide value to both the agile team, and stakeholder. This Agile Sprint Review is the perfect ceremony go gain this value.
So what can you do to enhance the effectiveness of your Agile Sprint Review? Here are some tips.
What is an Agile Sprint Review?
Before we get started with the Sprint Review Tips, let’s have a refresher of what is a Sprint Review/Demo.
According to the Scrum Guide, the Agile Sprint Review is described as:
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Schedule at the End of the Sprint and at the Same Time
Finding a time for a large meeting can be frustrating. One person may have an hour open here, but another only has 15 minutes. It can be endless back and forth trying to find a time, asking multiple people to move around meetings.
Booking a series of a meeting is far more simple. Since the Agile Sprint Review is an ongoing ceremony, it should be booked as a series. Using this tip, the Agile Sprint Review is booked as a series, it will allow key stakeholders to set that time aside. In the short term, there may be some one of meeting conflicts, but after a couple of Sprints stakeholders will be able to plan around the Sprint Review.
Scheduling the Agile Sprint Review at the end of the Sprint is key. Gaining feedback is one of the benefits of a Sprint Review, and being able to get this feedback right before Sprint Planning will allow the team to pivot quickly before committing to the next Sprint.
Understand the Target Audience and Present for Them
When you attend a presentation, or class, it is far easier to understand when they are speaking the language you know. A technical team will learn more when being presented with technical language, the same goes for key stakeholders. Understand their language, and present for them.
The focus of an Agile Sprint Review is to gain feedback from the key stakeholders, therefore they are the target audience. You may have more project team members but they are not your target audience. You may have technical people presenting, but they are not your target audience.
When a key stakeholder understands what is being presented to them, they are more likely to give feedback. They will also ask important questions. With this tip, a key stakeholder will be able to get a full understanding of the state of the project. Stakeholders will see the value in an Agile Sprint Review.
Use a Template
With any presentation, the content of the presentation should be the focus, not the quality of presentation. Utilizing a Sprint Review template can help maintain focus, which in turn will lead to valuable feedback about the product. A Sprint Review template will ensure that all the important information will be shared on a regular basis.
Using an Agile Sprint Review template will also provide other benefits. Future Sprint Reviews will be easier to put together. The key stakeholders know what to expect. And a Sprint Review Template can be shared with all the Agile teams in the organization, setting a quality standard.
Feel free to check out a Sprint Review template I use here.
Make a Quick Plan with the Team
Messy, unorganized presentations can be hard to watch. More time is spent by a team trying to get through a presentation, than the actual presentation itself. The Agile Sprint Review is not only to share the team’s work, but also to share the value of the team.
Spending a quick 15 minutes a day or two before the Agile Sprint Review will go a long way keeping the ceremony focused and valuable. Stakeholders will appreciate the professionalism of the Sprint Review. Leaving a good impression with the key stakeholders will encourage them to give valuable feedback.
This agile tip makes a quick plan is simple. Share a Sprint Review template with the agile team. Gather the team, after the daily scrum stand-up works best, and fill out the presentation. Ask for what was “Done”, “In-progress”, and challenges they faced. Allow the Product Owner to ask questions for details on each item in-case stakeholders ask questions during the Sprint Review. Encourage team members to demo work, and build a quick agenda.
Record Record Record
A company I worked for in the past had an issue with key stakeholders being able to attend a Sprint Review. Before I worked at the company, they did not start doing Sprint Reviews till years into their Agile Transformation. Once they decided to do some sort of demo or review, they came up with an idea. And was it bad. The Agile team would do a demo for 15 minutes, then they would do the demo all over again for 5 more times as people dropped in and out. Wouldn’t recording a meeting make much more sense?
Stakeholders should prioritize the Agile Sprint Review, but at times, other meetings do come up. But adjusting for one person, just frustrates everyone else. Recording the meeting will allow the stakeholder to go back and watch the Sprint Review.
Most meeting tools have a feature that will auto-record. Ensure this is turned on. Afterwards, share the link with everyone that was invited to the meeting. A quick email, or message in a shared chat room will do. Keeping an overview of the Sprint Review online with the link to the recording is helpful too. Provide a feedback method to those who missed the Sprint Review, any stakeholder feedback is valuable. This tip will get more viewers on your agile team’s work and more valuable feedback.
Share the Agenda ahead of Time
A finished product is not just used by the key stakeholders. Yes, they are your target, but they represent a group of employees or customers. At times, the other users may be interested in a specific feature. Instead of making everyone attend every review and hope their feature gets demoed, notify the other users about what will be discussed in the upcoming Sprint Review.
After you make the quick plan with your agile team, share with the key stakeholders will be reviewed. A tip is to send a quick email, or message will do. When the key stakeholder or leadership know what is going to be discussed, they can bring in other key people to attend. Saving other’s time from having to attend every Agile Sprint Review hoping they see the area they work with most.
The agile team will benefit too. Having the key stakeholders at every Sprint Review provides great high level feedback. But having specific users or customers will provide targeted feedback. As an added benefit for the whole project, you will be get fresh eyes on the product who will see things differently.
Summarize Done and In-Progress User Stories
The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk.
Transparency, one of the pillars of Scrum. Without transparency, the stakeholder does not know what is being worked on, or the direction of the project. In addition to demoing the product, quickly summarizing what user stories were done, and which user stories the agile is still working on will provide that transparency.
Transparency at the user story level highlight the amount of work it takes to go into each feature. Key stakeholders understanding the work will help them when they want to pivot. The stakeholders will have a general idea on how much effort a change will take.
Sharing the user stories that are done, and in-progress can be simple and quick. At the start of your Agile Sprint Review, present a list of these stories. Highlight which user stories will be demoed. Very briefly describe a bug, or technical debt the team fixed. This agile tip will help shareholders understand the direction of the agile team.
Share Challenges Faced to get Help from Stakeholders
Agile teams work best when they are supported by leadership and stakeholders. Support means more than a “good job” or a pizza party though. Support means having a team’s back when challenges arise. Communicating these challenges could be a challenge in itself. This agile tip will help you get the support your agile team needs.
Since your team owns and presents the Sprint Review, you control the message. Sharing the teams challenges highlights areas where stakeholders or leadership can help. When a stakeholder, or a leader is invested in a project, they will want the agile team to perform at their best. A strong leader will notice these challenges and help to address them.
Highlight these challenges and blockers after you discuss what user stories have been marked “Done”, and the user stories still “In-progress”. Mention challenges that you addressed as a team and briefly describe how you solved them. Add challenges you know leadership can help address. If the same challenges exists sprint over sprint, ideally the stakeholder or leader will notice a pattern and help. Asking for help in the Sprint Review will keep leaders and stakeholders attention too.
8 Seconds Rule for Questions and Feedback
Seeing the product, and the direction is the main reason why your stakeholders attend the Agile Sprint Review. Stakeholders want their voices heard, and questions answered, but how do they provide them when you rush to the next part of your Sprint Review. Give a stakeholder time to gather their thoughts.
The 8 second rule is simple. Once a part of the Sprint Review is done, whether it be a demo, review of challenges, or list of user stories, wait 8 seconds before moving on. 8 seconds provides the balance between uncomfortable silence, and rushing to the next part of the Agile Sprint Review.
Giving 8 seconds will allow at least one stakeholder to gather their thoughts and questions. Let them speak, and answer any questions. Before you know it, others will start to have feedback and questions. If the 8 seconds run its course without any questions or feedback, move on to the next part of the Agile Sprint Review. Applying this agile tip to other ceremonies works great too.
Keep an Eye on Time and Stakeholder Focused
This is where an Agile Sprint Review can deviate from its intended course. Team members going through long demos, providing too much details, and repeating themselves. Sprint Review attendees asking unrelated questions, monopolizing time from the key stakeholders. Other’s will start to multitask and miss important updates.
Limiting time of each team member is important. Going through very fine details of their demo provides little value to the overall key stakeholders. The stakeholders want to see the product, not fine details. The focus is on the output and presenting for the stakeholders.
Limiting time with the stakeholders is important too. Using this agile tip, you will get feedback and questions that are valuable and specfic. When a stakeholder begins to ask questions that are not related to the topic just presented, it can lead to a loss of focus on the priority item being discussed. Don’t be afraid to step in. Once you notice a conversation is taking too long, remind the stakeholder that more details can be discussed offline. Make an effort to follow up with that stakeholder afterwards. Following up with the stakeholder will ensure them that their voice will be heard.
When conversations are taking too long, or team members are not providing valuable information, people will start to tune out. Once people start to tune out, important information will easily be missed.
Non-technical Technical Demos
Everyone is proud of their work. Being acknowledged for that work is even better. Showing stakeholders and leadership shiny new interfaces or finished products gets a team member a lot of acknowledgment. But what about the technical work? Backend technical work only output is code, how do you show this work off and present the value to someone who is not technical?
Understanding the stakeholders language, present a high level overview of the user story or piece of work. Please provide the user story or feature that the technical aspect relates to. Give the non-technical value behind the work. Consider sharing a diagram or a link to high level documentation. An example could be an API improvement to increase loading speed. In this case, provide improvement time and the positive effects of a faster interface.
Fully engaged stakeholders and leaders want to provide feedback. This agile tip will get you that feedback. Showing only code to non-technical people will just confuse them. Speaking their language will help them understand the value of important backend technical work.
Ask for Feedback about the Sprint Review Itself
The Agile Sprint Review ideal output is feedback about the project the Agile team is working on. Getting constant feedback allows the team to pivot quickly. But there may be times when how the Sprint Review is presented does not help stakeholders. They may have additional Agile Sprint Review tips not listed here.
Working with key stakeholders to gather feedback about your Sprint Review format will help deliver the most value for them. Gather what the key stakeholders like, and dislike. Ask leading questions to understand their point of view. Ask for feedback after two or three Sprint Reviews to let them understand the Sprint Review.
Do not discuss feedback directly in the Sprint Review though. Meet with one or two of the main key stakeholders afterwards. Listen to their ideas. If you want to gather feedback from the larger audience, use a feedback form. No one wants to attend another meeting for something they can do in a feedback form.
Once you gather the feedback, adjust your Sprint Review to plan. Be prepared to not give everything a stakeholder may want though. Some topics don’t bring value to a Sprint Review, items such as certain agile metrics, retrospective discussions, or anything else that doesn’t require feedback. In the case a stakeholder ask for something not related to Sprint Review, work with them outside of the Sprint Review and discuss ways to communicate these other topics.
Conclusion
Implementing these tips will maximize the benefits of your Agile Sprint Review. Sprint reviews that provide key stakeholders and leaders with maximum value will help get a team the valuable feedback needed. With valuable feedback, the project’s output improves greatly.
Share in the comments what tips that work for you and your team to improve this important Agile ceremony.
Find these tips helpful? Check out my tips for other Agile ceremonies:
Tips for an Effective Daily Scrum Stand-up
Tips for an Effective Agile Sprint Retrospective
Tips for an Effective Agile Product Backlog Refinement
Tips for an Effective Agile Sprint Planning
👏 If you have enjoyed reading my article, remember to comment, clap, and highlight. It will encourage me to write more content.
