Sprint Review or Sprint Demo?
Oh, you think those are exactly the same, don’t you?
Welp… let me show you that your demo is most likely only getting you 10% of value a review is supposed to.
And if your team doesn’t do either, I have a few tips to help you get started with it.
Scrum Meetings
We know that every Sprint has four main meetings: Planning, Review, Retrospective, and Daily Scrum.
(if you don’t know or are not sure about this, I have a video called “What is Scrum?” that explains the framework in detail, so you should check it out)
I often talk about Retrospectives and I have a video about Planning and even the Daily Scrum.
But somehow I don’t really have a video about Sprint Reviews. So here it is!
In this video, I’ll show you an example agenda that you can literally just copy and paste in your Sprint Review invite, and also an example of a real-life remote Sprint Review from a video game company that I’ve been following. I absolutely love that example, so stay tuned.
Sprint Review Purpose
Sprint Review is essential to the success of your team… like any other meeting in Scrum.
But they may be harder to start because you need to involve stakeholders. And that often creates… let’s say, complications.
What is a Sprint Review and why do we need it?
“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.”
Or in simple terms: we review what’s been delivered this Sprint, share any challenges the team encountered, collect feedback from stakeholders, and discuss progress towards goals.
This serves a couple of purposes:
It creates visibility about where the team is at and how well they are progressing toward deliverables and milestones. That way stakeholders don’t need to constantly ask you what the progress is and whether we’re going to deliver on time.
It allows the team to get real-life feedback about their work and see how it contributes to the bigger picture. They don’t feel like they are delivering features into a black box to never hear about them again. And that provides a boost to motivation.
It creates the urgency to deliver something Done every Sprint. That allows the team to focus their efforts on completing work rather than starting it and ending up with lots of work items in progress at the end of the Sprint.
Sprint Review Agenda
With everything we’ve done so far we could create a Sprint Review Agenda, right? Let’s do it.
Here’s what I would add to the list:
- The Scrum Master may start by reminding everyone of the purpose of the meeting and the key points that will be discussed. Then next couple of points should be presented by the Product Owner.
- Start with discussing the goals, including the product goal or any other milestones the team is working towards.
- Then review the progress towards those goals. Are you progressing at the rate that you expected? How much work is left? It’s a good point to show any forecasts you might have.
- Then go into the presentation of the work done. This part is likely to be taken by the Developers who have done the work during the Sprint. It may be one person showing everything the team delivered or each person showing the part they worked on. The former is preferable.
- Then it’s time to collect feedback from the stakeholders. The Scrum Master may need to jump back in here, same as the Product Owner. You don’t want just to have a presentation and move on. No complicated questionnaires are needed – you just want to stop for a couple of minutes after each deliverable shown and ask to provide some thoughts. Is it aligned with their expectations? What did they like or didn’t like? What else is missing?
- Last but not least, discuss any challenges the team has been facing during the Sprint that prevented them from completing the work they planned in case it’s relevant. This can be a good opportunity to ask for help if you need some stakeholder authority to help you resolve some issues.
Just to summarize in brief:
- Remind of the purpose of the Sprint Review
- Discuss goals and milestones
- Review progress towards goals
- Present the work completed
- Collect feedback from stakeholders
- Raise any concerns or challenges
Simple!
Now you have the agenda. But where are the attendees?
Many times the teams won’t run the Sprint Review because their stakeholders are not attending, even if they have been invited.
Many other teams have Sprint Reviews where they don’t even invite any stakeholders.
That’s no good.
The whole point of the Sprint Review is to have a conversation with your stakeholders, so if they are not there – there is almost no point in a Sprint Review.
That actually reminded me that I do have this video I made on this topic…
In that video I talk about the common reasons for why Sprint Review is not happening and what you can do to overcome this challenge.
I don’t want to repeat myself here. So go watch that other video after you finish this one.
Sprint Review Meeting – Let’s send the invite
Ok, the agenda is created, the stakeholders are informed. But the team is hesitant to send out the invite.
This might be because they don’t want to show how much carry over they have, or maybe they are afraid of negative feedback.
Here’s what you can actually do to get to the point where the team is comfortable with the idea.
Step 1 – make sure you have a Sprint Review! Start with an internal meeting just for the team. The important thing is to actually have a live presentation. Since only the team attends, it will be less nerve-wracking for the team members.
Step 2 – invite other teams to attend. Your team may still be against inviting executives and directors even if they feel confident during their internal Sprint Reviews. So just invite some other teams that understand that technical side of work. For example, if your product is used by other internal dev teams – they are great candidates for the Sprint Review. This usually has two benefits – it helps the team get more comfortable with presenting their work to other people, and when the feedback is positive it usually makes them feel proud so they want to show their work to more people.
Step 3 – invite the stakeholders! Spend some extra time with your team before that first stakeholder Sprint Review. Maybe do a dry run just to make sure that everything is working.
And don’t forget to pray to the Demo Gods.
We all know the power of the Demo Gods when they are angry. That’s when that feature that you are showing stops working the second you start even if you’ve tested it 10 times before that.
Sprint Review Example
Let me show you an example of a different type of a Sprint Review that may give you some inspiration about what you can actually show to your stakeholders to keep them interested.
This is not an actual meeting, but instead an email.
For context. I’ve donated to a Kickstarter for a video game Sunless Skies when it was still in the works because I was a huge fan of the previous game the company has released.
This allowed me to be there for the whole journey as they started their work with Sprint 1.
Yes, they were using Scrum, mind you.
And every two weeks they would send us an overview of the completed work.
Watch the whole example in this week’s video!
Isn’t that amazing? It felt like I was there with the Scrum team.
I saw the progress every two weeks and I could provide feedback during their live podcasts on Twitch.
While this is not exactly your traditional Sprint Review it shows exactly what the Sprint Review is supposed to be. I haven’t seen any other company do it so well.
Well, that sums up this blog.
If you are looking for much more guidance on Sprint Review and every other aspect of running a Sprint, check out my guides, such as the Scrum Master Startup Guide and my Scrum Master Planner that are designed to help you facilitate every meeting with ease.
Remember, every time you make a purchase at the ScrumMastered store you earn Gummy Bears that you can redeem for some cool perks, like discounts and even free products!