We’ve talked about all Scrum ceremonies in the past. I’ll borrow the definitions from Jon’s article, but if they’re not enough, I encourage you to read his full article.
On a sprint review, the Scrum team shows stakeholders a demo of the progress. This helps evaluate where we are compared to our sprint goal, and whether priorities need to shift.
An important note – sprint review is not a demo. The focal points of the discussion should be establishing priorities and inspecting how the previous sprint got the team closer to the goal.
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
If it’s not obvious from the definition, this is a highly technical and “internal” process.
The two ceremonies have different purposes (product vs process), different attendees (stakeholders+team vs just the team), and very different outcomes.
Let’s discuss each of these in detail.
Sprint review is all about the product. This can be an application, a website, or even a physical commodity. You’ll be answering questions such as:
As you can see, these are very hands-on.
In comparison, a sprint retrospective focuses entirely on the process. If you’ve delivered less than the forecast, this is where you would inspect why that happened.
If something goes wrong and the software is released with a critical bug, the team traces their steps back during a retrospective to identify when the mistake(s) happened.
But they don’t forget about the good things either. There are plenty of lessons in saying out loud why and how the team succeeds. It helps embed that mindset for every member and allows them well-deserved praise.
Finally, the retrospective is NOT about pointing fingers. We work as a team, and share the ownership of everything that we produce. The focus is solely on the process, not the people.Summary
The sprint review is about the product and revolves around the end users of your product.
The sprint retrospective inspects internal processes and is team-centric.
I’ve already spoiled it above, but if you want a longer explanation or are just skimming the content, here it is.
The development team and the invited stakeholders attend the sprint review. It would be best if you weren’t afraid to invite as many stakeholders as you see fit. Just make sure they understand the purpose of a sprint review and don’t let them drift away from the agenda.
On the contrary, a typical retrospective is only attended by the development team. I’ve mentioned that some stakeholders might not understand the agile principles behind a review. Well, the retrospective turns it up to 11.
In this form, it’s a highly technical ceremony that relies on a proper understanding of the Scrum framework. If you have clients who are familiar with Scrum and who give you the psychological safety to be fully transparent during a joint retrospective, you’re sitting on a golden egg!
Otherwise, keep stakeholders away from the traditional retrospective.
You have the stakeholder input. Now what?
The earlier differences between the two ceremonies cause a stark contrast in the outcomes.
Starting with the review, the primary outcome is backlog refinement. And yes, agreeing that the backlog requires no changes is also very valuable. The frequent feedback loops of sprint reviews help you stay on course throughout the engagement.
It’s closely followed by stakeholder alignment. A review is not only an update for a stakeholder. It also gives them a chance to contribute, increasing product ownership across the entire team.
Finally, there’s the almost-taboo concept of the product demonstration. A review is not a demo, but it’s a very useful part of it. You can use the product to tell the stakeholders a story. It’s visual proof that users can complete activities that bring us closer to our goal. Awesome!
What about the retrospective? The outcomes reach way further. Identifying a problem during a retrospective can potentially change an organisation-wide process.
If a product error wasn’t picked up during a quality check, the outcome of a retrospective might be to improve that area drastically.
Perhaps there wasn’t a good understanding between the development team and the stakeholders. If you can identify that, you could change how often you communicate or change the tools you use for communication.
The outcomes of a retrospective can affect all of your clients and employees, whereas a review only focuses on a single product – a drop in the ocean in comparison.
Here are my answers to the top questions I’ve found comparing the two ceremonies. If there’s anything you’re still unsure about, please share it in the comments.
It’s the sprint review. Remember that the retrospective focuses on your entire process. The review is part of it and might be under scrutiny during the retrospective – so it must happen prior to the retro.
Yes. The Scrum guide proposes that reviews last one hour per week of sprints. For the retrospective, the recommendation is 45 minutes per week.
No. A typical Scrum retrospective is for the development team only.
I would encourage using a different framework to look back at your relationship with clients, though. Perhaps do it once every couple of sprints instead.
The Design Sprint is perfect for big challenges and audacious goals. But what about your daily “status report” meetings? They suck. We’ve all been there. Sign up for our newsletter and get immediate access to a PDF that will make them ten times better.
Originally published Feb 18, 2023 1:45:50 PM, updated June 1 2023.