Failing to include the agile team in quarterly planning reduces productivity. Use this guide to set more impactful and collaborative goals over 4...
Sprint Reviews: A guide to improving focus on outcome vs. output
I believed we could start the shift towards becoming an “outcome-focused” team by improving and defining our sprint review process.
For some teams, the culture behind focusing on outcome vs. output requires a more significant company-wide lift. However, I believed we could start the shift towards becoming an “outcome-focused” team by improving and defining our sprint review process.
Our team was previously accustomed to communicating sprint output at the end of every sprint. Still, we needed a process to improve focus on the roadmap while keeping attention to outcome details. We also wanted to balance this change with a well-facilitated discussion between our stakeholders and team.
Rather than focusing on what was completed by the time of a sprint review, our team becomes more outcome-focused by defining the impact on the overall roadmap. Here’s an example:
- The Agile Team initially estimates completing milestone X by time Y
- The Agile Team completes increments A, B, C but realizes they won’t meet milestone X by time YTime for the Sprint Review
- The Agile Team discusses impact on the overall roadmap with Stakeholders
- Stakeholders ask questions to The Agile Team for reasons around milestone X’s delay
- Stakeholders provide information about how milestone X’s delay impact revenue, other teams, etc.
- Stakeholders and The Agile Team discuss plans to complete milestone X by time Z and impact to overall roadmap
- The Agile Team shares demo of increments A, B, C
We still end every sprint review with a demo of the last increments. Participants come prepared to see something presented, and it’s an opportunity for the scrum team to showcase our product owner's prioritized items to the stakeholders. In addition, stakeholders provide information for the overall impact on the business, which offers more transparency and visibility across teams.
For us, the sprint demo is only a part of the sprint review. Think of the sprint demo as the icing on top of a cupcake. We combined them, but the review needed more defined objectives to create an outcome-focused team:
- Get feedback from the team and stakeholders regarding the roadmap.
- Review increments to the product and product backlog.
Here's what we'll cover today:
- Sprint review stakeholders
- Sprint review benefits
- Sprint review preparation
- A template for sprint reviews
- Final thoughts
Sprint review stakeholders
Before we dive into sprint review benefits, best practices, and agenda, here’s a breakdown of stakeholders involved in our sprint reviews.
- Product/Project Managers: primary presenter for sprint reviews and default presenter for information aside from demos
- Dev Team: primary presenter for sprint demos
- Varies per sprint review content: Anyone interested in our team’s work
Attendees can change depending on the content of the sprint review. For example, if the team has worked on price changes in Brazil, the international department might be more interested in it than sales and marketing in the US. Your varying attendee’s interests should always adjust your presentation priorities.
Sprint review benefits
Our product owner conducts the sprint review and uses the opportunity to discuss and revise as a team. Each of these items is essential to improving the product and sprint process.
Our style of closing a sprint with both a review and demo results in:
- Greater emphasis on sprint goals vs. points achieved
- Open dialogue for milestones and goals between every stakeholder
- Greater focus for Product Managers on our value to the stakeholders by articulating objectives and receiving feedback
Overall, there was greater vision alignment across all teams and stakeholders. Our sprint review provided a realistic time estimation for our goals and resulted in a transparent assessment from stakeholders. Ultimately, with greater team alignment, we focused on “The Big Picture” and OKRs rather than singular tasks/epics and actions.
Sprint review preparation
We’ve found some early success with our style of closing sprints. As we’ve learned to improve our sprint reviews, some best practices our team use to prepare for sprint reviews include:
- Prepare the deck beforehand (at least a week)
While avoiding procrastination is reason enough, preparing the deck beforehand gives teams a chance to discuss what they want to present during the sprint review. An earlier deck allows for more time to discuss and align on prioritizing important items within a 60-minute window. Most importantly, teams have time to gather the appropriate experiments and metrics to share during the sprint review.
- Retrieve a list of demos (one day before)
Since your team actively works on items up until the spring review, reaching out the day before gives them the best window of opportunity to know what will cross the finish line before the sprint review. The earlier you reach out, the more of an estimation you'll receive from your team. Miscalculated estimates may result in unmet expectations or inaccurate reviews.
We’re still learning to improve our sprint review process with every sprint. With these early preparation practices, sprint reviews become more efficient and focused while maintaining a manageable workload across the team.
Agenda template for the sprint review meeting
Now that we’ve covered the benefits of sprint reviews and some best practices for preparing for sprint reviews, here’s an agenda template for the sprint review meeting.
Time: 60 mins
Recording: Every Sprint review should be recorded and sent to attendees afterward.
Every sprint review
- Basic sprint performance (EM or TPM)
- Items committed
- Items picked up during the sprint
- Items completed
- Discussion of blockers, incidents, unplanned time off, and other issues that affected sprint deliveries
- Demos (PM introduces the concept)
- Progress against milestones (Our dates and changes to them)
- Next sprint theme/objectives
- Team changes
- new hires, people leaving
- Our process updates
- Any metrics we can share
- Any logging or experiment updates
- Discovery process updates
- Any expected “keep the lights on” work in coming sprints
- Client feedback PM has received: both positive and negative.
Alongside using the template above, provide a channel for stakeholders to ask questions. Facilitate ongoing communication by including channel details in the meeting invite and email sent afterward. As mentioned earlier, a core objective of this framework is to facilitate conversations between your team and stakeholders. Considering that this is an early template, we’re continuing to iterate and improve our sprint review process. Feel free to use this agenda as a starting point, and change it according to your team’s goals and needs.
Creating more efficient and focused sprint reviews/demos is an ongoing process — some might say even a work of art. Despite the primary function of sprint reviews to discuss goals, metrics, demos, and feedback, sprint reviews also create opportunities for cross-team collaboration and alignment.
Done well, it can build excitement towards the future. Sprint reviews like this will create an opportunity to share and build that momentum internally while communicating that synergy with various stakeholders. The communication and collaboration you achieve will be the best part of your sprint and a reward for a job well done!