Starting with Scrum: The Sprint Review

This is the sixth article in the Starting with Scrum series. 

• In the first article, we discussed how to get started with Scrum by determining what the Product Goal is. 
• In the second article, we talked about how to translate the Product Goal into a backlog. 
• In the third, we looked at Product Backlog Refinement. 
• In the fourth, we started the first Sprint with the Sprint Planning.
• And in the last one, we discussed the Daily Scrum, the one event that happens every single day of the Sprint and which helps us manage it.

In this article, we will talk about the event that concludes the Sprint: the Sprint Review.

What is the Sprint Review?

According to the Scrum Guide:

“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.” - Scrum Guide -

In this sense, the Sprint Review is the big moment when everything comes together. It is where the previous Sprint ends and the black box that is the team is opened, allowing the world to be awed by what they’ve accomplished.

It is also the first step towards the next Sprint. With the learnings from the previous Sprint, we have the necessary information to consider what comes next. It is the Last Responsible Moment.

The context for all of this is of course the Product Goal. While in the Sprint we focus on the Sprint Goal, the Sprint Review is the moment to reconnect with our higher purpose, the Product Goal.

The Demo

The first part of the Sprint Review is the demo (demonstration), focused on the learnings of the Sprint. The most important thing to remember is that this is not a status report or a moment for accountability, having the team prove they have been working, so to speak. 

Instead, the focus is on joint creativity, where all perspectives come together to collectively consider how the Increment helps to realise the Product Goal.

To encourage creativity and break the status report vibe, I find letting the stakeholders inspect the increment by themselves as much as possible works best. For example, if the team has delivered some new functionality for an app, just set up computers with the new feature and let the stakeholders play with it. If you have too many stakeholders, let them share. Have the team stay in the background and just take notes.

Or make it into a game. I’ve gone as far as to set the Sprint Review as a competition where stakeholders get points for everything they come up with that the team hasn’t thought of. Anything that makes it not a formal meeting should work.

Whatever the case, this playfulness and lack of structure draw stakeholders out of a position of power, out of their comfort zone. I think it works because playing with new functionality is often awkward. It brings everyone to the same level, and collaboration and creativity follow automatically.

The Planning

In the second part of the Sprint Review, we focus not on how to stick to any plans, but on how the most recent increment allows us to change the plan.

“Responding to change over following a plan,” as the Agile Manifesto puts it.

That is the whole purpose of this expensive meeting. Otherwise, why on earth would we bother with a whole demo, if we just want to check the boxes in a plan? We have decades of experience with that, and there are definitely more efficient ways to do so.

That’s why we start with the demo, so everyone is up to speed. We create a setting of creativity and collaboration where stakeholders can provide a fresh perspective — out-of-the-box thinking — while the team gets to validate their choices and the experience gained during the Sprint. That’s why it is so important to have the stakeholders there.

Then we channel that teamworking energy into collecting insights and original ideas to determine what the next step should be on our journey to the Product Goal, the Sprint Goal for the next Sprint. I find the 1–2–4-all technique works great here. With a few goals to choose from we can get the conversation going, not so much on which one is best, but why each one is important. It is the synergy of all those ideas we are looking for.

Whatever you do, stay away from the backlog! Not only is that level of detail unnecessary, but once your stakeholders start trying to get a grip off it, you can forget about anything creative. It’s like a black hole that sucks everyone into the details and gets them figuring out how to make ‘the plan’ happen. 

In fact, I think it’s smart to stay away from anything that looks or feels like a plan. Better to validate an existing plan by realising at the end of the meeting that you just recreated it, than to risk a loss in creativity!

Conclusion

I had a discussion recently with someone who questioned why I thought the Sprint Planning was the most important event in Scrum, instead of the Sprint Review. That got me thinking, and I realised I’d lost sight of that because it is such a hard event to get right.

Sure, it sounds simple, but in essence it is just a brainstorming session. However, it is also the event that gathers the greatest variety of interests and perspectives, making it into a minefield that is hard to navigate and get right. But if you really want to have an impact on your organisation beyond the team, it is the one event that makes that possible.

I leave you with what for me are the 3 most important factors to get right:

1. Ensure everyone understands the purpose. 

Easier said than done, but ignore this and a Sprint Review easily degenerates back into a status meeting. Or worse, a routine meeting nobody wants to go to.
Continuous repetition and a structure that reinforces that purpose helps. Liberating structures are awesome for this, as they not only help in keeping everyone focused on the purpose, but also make interactions more democratic.
Most important of all, redirect all requests for prioritisation, predictions, deadlines, roadmap details, and backroom politics to the Sprint Review. That is what it’s for! That’s the content for the 1-2-4-all I mentioned earlier, where we decide on goals for the next Sprint.
I think a Product Owner’s standard answer should be “take it to the review.” This will not only make the Sprint Review much more interesting, but will also make the life of the Product Owner a lot easier.

2. Focus on engagement and interaction.

Have a few Sprint Reviews in a row and your stakeholders will stop coming. So whatever you do, always ask “what would our stakeholders want to see?” when preparing the Sprint Review. It’s a bit like in the Sprint, where we continuously think of the value for the customer. The Sprint Review has to have value for the stakeholder.
Oh, and deciding “we have nothing to show” is rubbish. In a complex world we are always dealing with uncertainty, so help from our stakeholders is always good! The trick is to get creative. Feel free to be selective about which stakeholders you prepare a Sprint Review for, and be clear about it.
And take your time with it! When was the last time you were at a Sprint Review that took 2 hours? Sounds ridiculous, right? But that is what the Scrum Guide recommends for a 2-week Sprint.

3. Keep control of the event in the team. 

Ideally, the team owns and shapes their Scrum process, so it is only logical that they also define what is maybe the most important event in that process if done right. Furthermore, they are usually more mature in Agility than the average stakeholder, so they are better equipped to execute the Sprint Review in an Agile way (avoiding a meeting!).

Allowing the team to design the Sprint Review allows them to continuously improve it, subjecting it to the same empirical rigour they apply to all other aspects of their work.

‍

FAQ about Sprint Reviews

Why Is Sprint Review Important?

Scrum teams use sprint reviews to get more agile through the automation of communication processes.  It means asynchronous reports, surveys, and even some meetings become automated. A sprint review offers an unbiased perspective about employees’ work experience and personal journey.

Managers use sprint reviews to get familiar with the elements that impact the team’s productivity the most. Sprint reviews help managers ask the right questions and build solid relationships with other team members. Afterwards, stakeholders and team members look at completed tasks and establish the purpose of the next meeting.

Sprint reviews allow teams to get a clear idea about the current progress of the project.  A scrum team can assess the goals, strengths, pitfalls, and future potential of the project. In the digital age, sprint reviews have become the answer to inviting more collaboration and teamwork, making it easier to set suitable project timelines and meet targets before the deadlines. Sprint reviews also involve stakeholder engagement and make them part of the product development process. One final reason that sprint reviews have become so practical and popular: they maximize the quality of a project!

How to Use Sprint Review

For starters, keep the sprint review casual rather than allowing it to devolve into a simple presentation. Make sure to allocate enough time for the meeting as well, but be willing to let teammates go early if the discussion is over– as opposed to keeping them and wasting everyone’s time. These best practices are bound to increase feedback and participation and make it easier to schedule the next sprint review meeting.

When it comes to using sprint review, you should also ensure that the project management platform is visible. You need to leverage project management tools and provide the best visual representation of the existing project to bring everyone on the same page and encourage more discussions.

In modern-day informal sprint reviews, you have to celebrate your wins and show appreciation for the team on current progress. This is the best way to build healthy communication among team members and make each sprint review successful. Focus on short sprint reviews, but make sure your whole team remembers the long-term project goals.

How to Run a Sprint Review

First and foremost, it all starts with reviewing the results of an iteration. Developers take care to explain to Project Managers what was finished, and what is still incomplete after the previous sprint.

Next, Product Owners will go into the backlog and decide upon a few achievable goals– like projected release dates for future product improvements.

Then, the team will have a discussion about what their next steps and ideal performance should look like. This input will be incredibly useful when the team eventually reaches the planning meeting for the next sprint.

After this, the team will do some market analysis and see if their positioning relative to use-case or competitors has changed. Finally, they will finish the meeting with a revised product backlog and some new ideas / tactics for how to tackle the coming iteration.

‍