In this article, we discuss how to run a sprint review meeting. The purpose of the sprint review meeting is to ensure that we have an updated product backlog before we start the next sprint. We need to take some time to make sure we are building the right thing and heading in the right direction.
- A meeting held at the end of a each sprint
- Timeboxed to 1 – 4 hours per sprint (1 hour per week of sprint length is a good ballpark)
- Required attendees: The whole development team, Scrum Master and Product Owner and any stakeholders (invited by product owner) who can provide useful feedback
- A laid back, fun, informal meeting, not a status update
- The Product Owner reminds everyone what the sprint goal was, whether it was achieved and the stories completed that contributed to the goal. The Product Owner also describes what was not complete during the sprint
- The Development Team have an opportunity to discuss any issues they had to overcome, or anything they are still struggling with
- The Scrum team shows the work that was completed (only the completed items) and answer any questions about the sprint
- There is a discussion on anything relating to the market conditions that our product operates in
- And finally, any potential items that might go into next sprint are reviewed
- At the end of sprint review, you should have a pretty good idea what we are doing next – the purpose of the meeting.
Example of a Sprint Review meeting
At my current workplace, we use the following format for sprint review; it works pretty well for us, but as always, there is room to improve and every team is slightly different. Use your next Sprint Retrospective to discuss how your Sprint Review meetings are going and how you can improve.
The day before the meeting starts (usually on a Friday for us), the team decides how they are going to run the meeting; who is going to demo what functionality, the order of things they might say etc… We don’t spend more than a few hours preparing for the Sprint Review; it should be more of a natural end to a sprint, a snapshot of the progress at the end of the day.
You also need to make sure you have a big enough space booked in advance (preferably regularly booked so you don’t have to worry about it again). The sprint reviews in my workplace generally consist of the team whose sprint is ending, the product owner and relevant stakeholders, plus any number of any other development team members who are interested. We are very lucky to have such a great turnout to sprint review every single sprint.
💡 Top Tip
As Scrum Master, I’m there to facilitate this meeting, to make it easier. In this regard I ensure the meeting is set up, that the right people are invited, the right sort of discussions are happening and that we stick to the time box. I also take reams of notes each meeting that are shared with the team afterwards; so that they can concentrate on “doing the meeting”.
When is it?
The meeting is scheduled at the end of every sprint, and the Product Owner owns the meeting invite. The ownership of the meeting invite easily allows the Product Owner to forward it on to the relevant stakeholders as and when required.
Our sprint ends on Friday afternoon, so the sprint review is scheduled for Monday morning, and our Sprint Retrospective and Sprint Planning sessions are scheduled later that afternoon and into Tuesday morning.
Who starts it?
The Product Owner usually opens the meeting by welcoming everyone and mentioning any new faces that might be around.
Mentioning new faces allows everyone to be familiar with who everyone is, maybe you invited a different stakeholder to the meeting this Sprint; it makes everyone feel comfortable.
What do you talk about?
At the end of the sprint, our sprint backlog items have one of two states:
- DONE – We finished the item (satisfying our definition of done)
- NOT DONE – We didn’t finish the item
The Product Owner describes what was DONE and what was NOT DONE, and anything that is DONE is suitable for a working demonstration to the group for immediate feedback. We do not recognise partially done work.
If you are very lucky, the stakeholders would have already been involved in the product development at an earlier stage, providing even earlier feedback and thus reducing the cost of building the wrong thing right from the start.
The sprint review might not be the first time a stakeholder has seen the new functionality. In this case, you may find this part goes a little bit quicker. That doesn’t mean you should skip demos though; other people are in the meeting, they may have seen an earlier version and haven’t seen the final version yet.
After the demonstrations of working software, everyone should have a shared understanding of what was done, what was not done, and we have covered two of the three pillars of empirical process control; transparency and inspection. We now move on to the third pillar, adaption.
Review plan for next sprint
A group discussion is held to ensure that what we are doing next is the right thing to do, and whether we we need to adapt our plan based on new information gleaned in sprint review.
Our plan consists of the product backlog items we might take into the next sprint, and any releases we are thinking of doing in the near future, with approximate dates based on our teams current velocity.
The result of all this is an up to date product backlog ready for our next sprint planning session where everyone is on the same page, right from the start.
Top 5 tips for an awesome Sprint Review
1. Focus on the purpose of the meeting
The purpose of the meeting is to ensure that the product backlog is updated with the latest known information, so that our investment in the next sprint maximises the value we can deliver. It’s not just about showing what you’ve done (although that helps build trust that the team can deliver on a regular basis).
2. Get a big open space in your office with a screen
Let’s celebrate how awesome our recent updates are as a big group. This is not fun in a cramped room. So make sure you have a big space to gather a large crowd in! Make sure everyone can see and hear what you are saying.
3. Invite people virtually
If people can’t physically make it, make it available virtually; e.g. a conference call.
You may wish to record the meeting, but be careful here, stakeholders might just stop attending in realtime, then you miss a chance for immediate feedback before your sprint starts. You really do want people to be there “live”during the meeting for maximum impact.
4. Prepare for the meeting, but not for too long
It’s a lightweight, fun meeting, but that doesn’t mean we just wing it every time. There is an amount of preparation you need to do.
As Scrum Master, your role is to facilitate this meeting (to make it run smoothly); but in order to prevent ping-pong between Product Owner and Scrum Master during the meeting, I like to agree with the Product Owner that they will take care of the meeting invites, starting the meeting, and liaising with the development team to decide how demos are going to go.
There is a right amount of time to spend preparing for this meeting before you get diminishing returns. When you first start out, you may need a bit more time to prepare, but as you get used to it, you’ll find it’s the natural end to every sprint. I’d recommend spending no more than 2 hours getting everything set for sprint review.
5. Invite the right people, ask for feedback
When you conduct a Sprint Review meeting, you are asking a large group of people for their time to review the work that’s happened in your sprint. For that reason, it’s important that you invite the right stakeholders to your sprint review; those stakeholders who have an interest in the product you are building. If you invite the wrong stakeholders, you could be wasting their time.
I find the best way to find out if stakeholders think Sprint Review is worth it, is to ask them. I put together a simple poll after each Sprint Review and check:
- Everyone thinks it’s worth their investment in time
- A star rating from ⭐️ to ⭐️⭐️⭐️⭐️⭐️
- Any additional comments on how it could be improved
Sprint Review is a critical part of empirical process control; we make our progress and decisions transparent, we inspect the product and the market it’s in, and we adapt our plans to maximise value in the future.
I hope this article helps improve your Sprint Reviews, and please share this article with anyone else you think would benefit.
Till next time.