For those who are brand new to agile (Scrum, specifically), or for people who get thrown onto an agile team without proper training, I have seen a ton of confusion about the purpose of a Sprint Review. Let me help clear this up:
What is a Sprint Review?
According to The Scrum Guide, written by Jeff Sutherland and Ken Schwaber, 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.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities…”
The Scrum Guide
Let me break this down a bit further…
Inspect the outcome of the Sprint
The outcome of the Sprint should be working software (or product) – also called the “increment.” According to the Scrum Team‘s “Definition of Done,” the completed work is shared with the key stakeholders so they can give feedback about what was developed.
Determine future adaptations
Based on the feedback received from the stakeholders, the group determines what future adaptations they desire. The information is captured for evaluation and consideration by the Product Owner and is added to the Product Backlog.
Scrum Team presents the results of their work
The Scrum Team presents their work – not just the Product Owner or the Scrum Master (although one of them may facilitate). The Developers did the job to create the product, so they get to showcase it. Each person shows their own work. Standing in front of an audience is often challenging for some Developers, but it’s an opportunity for them to step out from behind the curtain and take the credit they deserve.
Progress toward the Product Goal
Every Sprint should have a Sprint Goal that supports the overall Product Goal. During the Sprint Review, progress toward this goal is discussed. There are several ways to facilitate this conversation, using tools such as a Product Roadmap, a Burnup Chart, or any other format that reflects progress toward the Product Goal.
Stakeholders review what was accomplished and what has changed
Each Sprint Review includes all the work previously done plus anything added to the product during the Sprint. If anything has changed, the changes are also reviewed. As mentioned before, stakeholder feedback is elicited and fed into the Product Backlog.
Attendees collaborate on what to do next
The Sprint Review also includes creating a plan for what to do next. The Product Owner may have a tentative plan at the start of the session, but it may be changed and adjusted based on feedback from the stakeholders and the rest of the Scrum Team – all participants collaborate on this plan.
Product backlog may be adjusted
In addition to adding new items to the Product Backlog, other necessary adjustments may be made. Items might be removed, modified, or re-ordered based on the group’s agreement on what to do next.
Who should attend the Sprint Review?
The Scrum Team (Product Owner, Scrum Master, Developers), and any key stakeholders. A stakeholder is anyone who has an interest in the product. A key stakeholder is someone whose opinion matters. It could be the person funding the team or the product, your internal subject matter experts, or even external customers.
TIP: be sure that everyone who needs to be there attends because if you miss stakeholders, you will likely miss requirements.
How long should a Sprint Review take?
The length of your Sprint Review is based on how long your Sprints are. Like all events in Scrum, there is a maximum time box – for this activity, it’s three hours. If the iterations are shorter than four weeks, the amount of time it takes will probably be less.
When does the Sprint Review happen?
The Sprint Review happens at the end of each Sprint and is the second to last event of the iteration (the final one is the Sprint Retrospective).
TIP: It’s a good idea to schedule all Scrum events as recurring meetings so they are on everyone’s calendar well in advance; this blocks out the time and helps ensure the right people attend.
What the Sprint Review is NOT
A Presentation
“The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation”
The Scrum Guide
Let’s repeat that last part: “…the Scrum Team should avoid limiting it to a presentation.” You don’t need to have a fancy PowerPoint, but you should have an agenda. What you share at the Sprint Review should be the actual working software or product – not a facsimile. The point is to show the work and get feedback.
Sprint Planning
While you do high-level planning in the Sprint Review, it is not the same as Sprint Planning, but I have some teams use it as such. Sprint Planning is a totally separate Scrum event in which the team determines their Sprint Goal and how they will deliver on that goal.
Just a Demonstration
While the demonstration of a working product is a part of the Sprint Review, there’s a lot more to it than just that (re-read the first section of this blog). People who believe that the only point of a Sprint Review is to see a show-and-tell and then walk away are wrong.
Sprint Retrospective
There’s a time and place for candidly talking about how things went during the Sprint, but that’s stuff the stakeholders don’t need to see. They want to see what your Scrum Team delivered. How things went is discussed in the Sprint Retrospective.
TIP: Also, use caution, and don’t let your Sprint Review devolve into a complaint session or a blame game – that’s not helpful for anyone.
A Facsimile (Rather than Working Product)
I have (sadly) attended Sprint Reviews at which the real increment could not be shown due to technical challenges. Rather than being honest with the stakeholders about the state of things, the Scrum Team created a “fake” version of what the product should do and showed that instead of the real thing. This may have been a reasonable workaround, but you should always be truthful and transparent with your stakeholders (and they almost always understand).
Final Thoughts
The purpose of the Sprint Review seems very simple, but it turns out there are many ways it can be derailed and used for the wrong thing or in the wrong way. Make sure everyone knows the purpose up front so they can come prepared to do what they’re supposed to do. Then hopefully, you’ll be able to avoid having your meeting hijacked for incorrect uses.
How about you? Are you following the Scrum Guide or doing something different in your Sprint Reviews? I’m curious to see what others have experienced, so if there’s anything you do differently, please share it with me in the comments!