I once was at a client, working with about twelve teams doing Scrum. They had this setup where every Friday after lunch, all the teams would gather for their Sprint Reviews. Big room, lots of stakeholders, the works.
But here’s the thing: they were doing Sprint Retro before Sprint Review.
When I pointed this out, I got the response I’ve heard a few times: “Claudio, you go by the book too much. It doesn’t matter.”
The Feedback Loop You’re Missing
Think about what happens in the Sprint Review. You spend two weeks working hard. Multiple people, many hours, building something you believe will deliver value. You have two hours to demonstrate that work to stakeholders (in the situation above, each team had 10-15 minutes).
Those two hours are when you find out whether all that effort aligns with what the business and its stakeholders actually need.
Sometimes it goes great. Sometimes stakeholders say, “Yeah, that’s exactly what we needed. But now that we see it, we need this other thing too.”
And sometimes they say, “That’s not at all what we need.”
All of that is feedback. Critical feedback. Feedback about how well you understood the problem, how well you communicated the solution, and how well you read the room.
If you do Retro before Review, where does that feedback go?
Nowhere. You wait until the next sprint’s Retro to discuss it. By then, you’ve already done another Review without improving your approach to it.
It’s Not Just About Building, It’s About Showing
A lot of teams think Retro is just about how you built the system. The technical practices, collaboration, tools, and process.
That’s part of it. But if you spent two weeks building something and then tanked the presentation, the sprint wasn’t successful. Period.
Sprint Review is part of the work. It’s not a formality. It’s not just “demo time.” It’s where you find out if the value you thought you were building actually landed.
Did your storytelling (or story-showing) connect? Did the stakeholders understand why this matters? Did you notice their reactions when you showed certain features? Did you create space for them to give you the feedback you need?
These are things you should discuss in Retro. But you can’t discuss them if Retro happens first.
The Real Cost of Getting It Wrong
Here’s what I saw at that client. Teams would show up to the Sprint Review unprepared. The Product Owner would do most of the talking. Developers would click through screens that showed buttons and dropdowns, but didn’t connect them to the business value.
Stakeholders would sit there, in an expensive meeting, lots of people in the room, watching a spinning wheel because the demo environment was flaky. Or they’d hear about “user story XX1-953” without understanding why it mattered.
By then, Retro had already happened. So the next Sprint Review would go the same way.
With teams that follow the order, Review then Retro, they often go to Retro and talk about their code quality, their velocity, and their technical debt. All important things. But they completely miss the fact that they failed to communicate the value of their work.
The next sprint, same thing. Because they never reflected on how the Review went.
What Changes When You Get the Order Right
When you do a Sprint Review first, then a Retro, you create a complete feedback loop.
In Retro, you can ask:
-
How did we do at presenting our work?
-
Did our storytelling connect with the stakeholders?
-
What did we notice about their reactions?
-
How can we help the next sprint presenter feel more comfortable?
-
How can we design better Sprint Reviews?
You can talk about the technical work and how you showed up for the people you’re serving.
You can discuss what went well in the Review and what needs improvement. You can coach the presenter. You can refine your approach to demos. You can talk about whether you’re focusing on features or outcomes.
All of that makes the next Sprint Review better. Which makes the next sprint better. Which makes the product better.
It’s in the Guide for a Reason
The Scrum Guide places the Sprint Review before the Sprint Retrospective for a reason. It’s not arbitrary. It’s not just “by the book.”
It’s because Retro is where you inspect and adapt your process. And the Sprint Review is part of your process.
If you’re not inspecting how well you demonstrated value to stakeholders, you’re missing a huge opportunity to improve.
The teams I’ve coached who made this shift, they get it pretty quickly. Once they experience a Retro where they can discuss what happened in the just-ended Review, they don’t want to go back.
Because now they’re not just building software. They’re learning how to show the value of what they build. They feel they’re in a working session with the stakeholders. And that’s what makes the difference between a team that delivers features and a team that delivers outcomes.
A Simple Question
Next time you plan your sprint events, ask yourself: when and how will we reflect on how well we communicated our work to the people we’re serving?
If the answer is “two weeks from now,” you’re waiting too long.
Leave a Reply