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 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.
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!
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.