The differences between a sprint review and a retrospective

Definitions of a review and a retrospective

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.

What is a Sprint Review

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.

What is a Sprint Retrospective

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 differences between a review and a retrospective

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.

The purpose of reviews and retrospectives

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:

• What have we delivered in the last sprint?
• Has the past sprint brought us closer to our goal?
• What has changed in our requirements and how to prioritise the next sprint?
• Are there any blockers that need to be resolved?

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.

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.

Who attends the review and retrospective?

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.

The outcomes of a sprint review compared to the retrospective

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.

Frequently Asked Questions

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.