Build better products by making Sprint Reviews fun.

*Developer shares screen and in a monotone voice reads the list of tickets completed from Notion/Trello/JIRA Kanban*

If you work in an Agile software development environment, you will have likely experienced the Sprint Review ritual, which ceremoniously marks the end of one development cycle. The goal of this article is to understand the fundamental purpose of a Sprint Review and how to change your team's pre-existing negative narrative and turn it into a session that people look forward to.

Recently I have been working with a large corporate going through a digital transformation. 9 Scrum teams, each with 8–12 members in each squad. One recurring topic that comes up during my 1:1 coaching sessions is that Sprint Reviews are not engaging and don’t provide any value, except as a management report. Many of the Scrum Masters I am working with are developers by trade, looking to improve their leadership skill set, but struggling to understand the true value of a Sprint Review.

In order to make our Sprint Reviews engaging, we must take a step back to understand its purpose:

“The purpose of a Sprint Review is to Inspect the outcome of the sprint and determine future adaptations”. — Scrum.Org

The two keywords in the definition are “Inspection” & “Adaptation”. A “Sprint” is a set period of time where a team aims to deliver an increment of work that 1. Provides your users with value, 2. Creates a feedback loop to improve your product going forward. As a product team, at the end of the Sprint, we must inspect the done increment of work to see what improvements can be made to achieve our product goal. Having these weekly/bi-weekly/monthly sprint checkpoints enables the team to take a step back and assess the progress towards the bigger goal. Without facilitating this time, you run the risk of developing a product that doesn’t adapt to the requirements and changing needs of your users.

You’re probably thinking “Bayley that's all well and good but how does this help me make my Sprint Reviews more engaging? I am already showing the product and product backlog to the team and stakeholders?”.

These are all valid points. I have worked on several projects where we do the product demo of the work delivered in the sprint, we get stakeholder feedback, and move on to the retrospective… yet it feels uninspired. Purely having the theoretical knowledge of delivering a Sprint Review will enable you to functionally deliver the session, but the outcome will produce surface-level actions.

How can you tell if you are running a “Functional Sprint Review”? If any of the statements below sound remotely similar to your Review session, you will likely fall into this category.

• *Developer shares screen and in a monotone voice reads the list of tickets completed from Notion/Trello/JIRA Kanban*
• “Let's just skip the Demo and save time for planning”
• “The latest PR is merging so this feature is done but you can’t see it. I can show you in my local environment, give me 2 minutes.”
• “Production isn’t up to date, but we can show you on Staging but some features aren’t merged here.”
• “When is feature x getting done, we have to prioritise this?!” *Outside stakeholder with little context*
• “Let's pull up the burndown chart, we’ve almost finished all our EPICs so we’ve almost succeeded in this phase.”
• *Several external stakeholders dictating what the team should build based on no user feedback data*

Sessions resembling these statements have probably left you with a sense of lethargy, frustration, and lots of wandering eyes… So let's figure out how to take it to the next level.

3 Steps to make your Sprint Reviews Engaging

Rally & Remind the Team of the Bigger Picture

For a previous client building a home repairs marketplace, we would start the Sprint Review by simply repeating our 1 line North Star vision. It is easy for developers, scrum masters, and stakeholders to lose track of the wider vision when our day-to-day focus is on micro delivery. Use this time to take a step back and remind the team of the wider vision. You will start to see your team more proactively challenging your product roadmap and prioritising work that contributes to that vision.

2. Share User Feedback with your team

Nothing is more powerful than the voice of your users. I have found that inspecting the outcome of the Sprint, doesn’t only mean a demonstration of the technical implementation of a feature/new product. Sharing verbatim feedback from your users changes the team's mindset. Many development teams will never meet their end-users, so hearing the response of their work shifts your team's focus from transactional outputs to value bringing outcomes.

For several projects, presenting feedback in the review like the slide above had three major benefits:

1. Reduce the noise of external stakeholder requests by listening to your customers first.
2. Encourage the development team to solve the user's problems, rather than focusing on delivering features for the sake of it.
3. Empower developers with a sense of ownership of their work.

3. Show the impact of the work that has been done

By sharing, clear quantifiable metrics, the development team can begin to help in problem-solving. Often in my teams when we shared a clear, quantifiable goal we found that the team would start coming up with more creative countermeasures to achieve our target.

Too often Product Owners take on this burden alone when there is an untapped pool of knowledge from the development team who know your product most. I have found that simply by reviewing the outcome of the sprint and the impact it had on our indicators, we saw huge improvements to achieving these goals. Some of the topics included:

• Technical Performance (Page response time, reducing server cost, etc…)
• Customer Satisfaction (Net Promoter Score, referral rates, etc…)
• Cohort analysis (Page conversion, app stickiness, etc…)

I’d recommend starting with one topic that your team would like to improve, start measuring the topic, whether good or bad and share it with your team. Similar to the points mentioned in sharing feedback, it is empowering for your team to see the impact on these measurable KPIs, rather than just being devs-for-hire.

Tactical tips to make the review better:

• Don’t show the kanban board/Trello/JIRA unless absolutely necessary. You are demoing the product, not the arbitrary number of story points you’ve completed.
• Protect the team from stakeholder noise. Save time at the end of the session for questions and allow your product owner to filter down requests from external stakeholders.
• Prepare a set of slides with a clear agenda. Too many sprint reviews go to the last minute as they are unstructured and often conversations result in no real resolve.
• Ask your Product owner to prepare the product demo in advance, even doing a screen recording of a user journey to make sure we can demo everything smoothly. More often than not, something will go wrong in the demo so it is best to prepare for it.

Conclusion

If you take anything away from your article it's this: empower your teams to take ownership of the product you are building. When problem-solving the needs of our users and creating unique experiences for them, we are stronger as a collective.

Let's hope your next sprint review session has people on the edge of their seats rather than falling asleep…