Here's a quick experiment. Ask your stakeholders, on a scale of one to ten, how valuable is your sprint review? I bet they'll say four. Now go ask your team the same question. I bet they'll say three.
Everybody knows. Nobody says it out loud.
So that's what I want to talk about today: the most expensive meeting in your sprint, and how to fix it.
The sprint review is the one event in Scrum where the business and the team are actually supposed to meet and collaborate. We do hold it in practice. But what has happened instead is that it has quietly become a demonstration, a polite one at that. Sometimes a genuinely cool one. But almost never do real decisions get made by the stakeholders. This week, I want to try to fix that.
Now, I already know what some of you are thinking: "Lance, we don't use Scrum, we're just trying to be agile." That's fine. Scrum is the most widely used agile framework, and it has been for many years, so I'll use its language. But the sprint is just a fixed-length, time-boxed iteration where a team tries to deliver a usable increment. If you don't practice Scrum but you're trying to be agile, you're still doing iterative and incremental development, and at some point you need your stakeholders or users to inspect what you've built. Call it a sprint review, an iteration review, or a stakeholder check-in. It doesn't matter. The whole point of agility is that we organize ourselves to show real work to our stakeholders as quickly as possible with the least amount of friction. As long as you have a way to get feedback, this one is for you.
A Sprint Review That Changed Nothing
Picture a Thursday afternoon at a mid-sized fintech. Ninety minutes are blocked off. Ten engineers, three product folks, a VP, and a couple of stakeholders from operations or marketing. The team spent the morning rehearsing the demos, loading the data, refreshing the sandbox. They're doing all the right things.
The product owner kicks it off. Engineer number one shows a feature. The VP nods. Engineer number two shows another feature, and someone asks, "Is this in production yet?" Yes. Cool. Engineer number three shows a new dashboard. Polite questions, polite answers. Everything's going well.
Then, forty-five minutes in, the room goes quiet. The product owner asks, "Is there any feedback?" That's the right question. The VP says, "Looks great, let's keep going." The meeting ends, everyone closes their laptops and returns to their busy lives.
And that was the sprint review. Nothing changed about the next sprint. Nothing was learned that wasn't already known. The team feels like they performed. The stakeholders feel like they showed up. So what's the problem? Nobody's going to call it waste, because everyone is too polite.
The Format Is the Problem, Not the People
Here's the truth: it's not that the meeting was bad. The people were trying. The people weren't bad. The meeting was bad because the format didn't require a decision.
That's really my whole philosophy on it. If the meeting does not require evidence or a behavior change, then what are we doing? I don't think the work we do is so simple that it doesn't require that. When a meeting rewards looking productive instead of being honest, the work bends to match the meeting. People learn to fly under the radar and not raise any questions, and pretty soon you've built a feature factory, one well-rehearsed sprint review after another.
Three Ideas That Reframe the Sprint Review
Let me give you three ideas that I think will reshape how you see this event.
1. The Scrum Guide Is Unambiguous: Inspect and Adjust
If you practice Scrum, let's talk about the Scrum Guide, not as a Bible or a religious artifact, but as a plainly written document. It is unambiguous about what the sprint review is for: the Scrum team and stakeholders inspect the sprint results and adjust the product backlog as needed.
Inspect and adjust. That's the whole job. Not present. Not impress. Not update.
The word most teams skip is "adjust." We sort of inspect, but we rarely adjust. And if you aren't adjusting, I don't know that you're running a sprint review. You're running a status meeting in a costume.
2. Flow: Delayed Feedback Compounds
In product development, the consequences of failure grow exponentially when feedback is delayed. Every engineering decision becomes a predecessor for many later decisions. So when you ship something in two weeks but it takes eight more weeks before anyone in the business asks the hard questions, you're paying compounding interest on bad assumptions.
The sprint review exists to short-circuit that compounding interest. It's supposed to be the moment where the bet meets reality and we find out whether we got the payoff. When that moment becomes a demo, the compounding doesn't stop. It just hides better.
3. DORA: Fast, Honest Feedback Loops Predict Performance
DORA research keeps reinforcing what high-performing teams already know: fast, honest feedback loops are not a nice-to-have. They are among the strongest predictors of whether a team improves over time. Teams that learn fast tend to pull ahead of their competition. Teams that ship faster than they learn can lose, and lose loudly.
Put those three together and you get a simple conclusion. The sprint review is your feedback loop with reality. The Scrum Guide tells you what it's for. Flow tells you why delaying it is expensive. DORA tells you that the teams who treat it seriously are the ones who pull ahead.
So why is it so often just a demo?
Why Reviews Quietly Become Demos
Most sprint reviews become demos because nobody pushed back when they started becoming demos. The team wanted to show their work. Leadership wanted a window into it. And the product owner didn't want to disappoint anyone. Demos feel safer than decisions. They don't require a hard call, they don't surface missed experiments, and they don't put anyone on the hook for changing direction.
But there is a cost, and it shows up in slow motion.
First, stakeholders learn that the meeting is optional, because nothing in their world changes as a result. So they stop coming, or they show up and open their laptops to check email. They could have done that at their desk.
Second, the team starts optimizing for what looks good in a demo rather than what drives an outcome. That's how feature factories get built.
Third, you lose the only forum where the business and the team are supposed to wrestle with the same evidence at the same time.
The Decision Test: Three Questions
You can fix the format. The people are already in the room. So let's agree on the premise first: the sprint review is a business decision meeting. The deliverable is a decision, not a demonstration. Once you accept that, the structure changes and the mentality changes.
I use a small test with the teams I coach. I call it the decision test. There are three questions.
If you can answer all three questions at the end of your review, you ran a sprint review. If you can't, you ran a demo.
Question one: What outcome were we trying to move this sprint? Notice the word outcome. Not which stories did we finish, not which features did we ship. What were we trying to change about user, customer, or business behavior? If you can't state that in one sentence, the rest of the review will drift because there's nothing to anchor it to.
Question two: What evidence do we have that the outcome moved, or that it didn't? This is where teams flinch. Evidence is uncomfortable. Sometimes it's a usage metric, sometimes a customer quote, sometimes a support-ticket pattern. Sometimes it's a clean "we don't know yet, and here's what we'll measure next," and that's a totally honest answer too.
I remember Jeff Sutherland, one of the creators of Scrum, talking about some of the very first teams he worked with. They'd get in a room to demo the working product so they could get feedback. After the first review, the team didn't want to go back, because it was that uncomfortable. People were throwing hard questions at them: Why did you build it that way? What customer is going to use this? What's the next move? The review turned into a real debate about business outcomes. Even in the earliest days of Scrum, it was uncomfortable for the engineers, and I think that's a good sign.
Question three: Given what we just saw, what is the next bet, and who decides? Do we continue, pivot, or stop? I want a named owner, a timestamp, and a decision logged in writing before the meeting ends. If you can't make that call in the room, you don't have evidence. You have opinions.
Why Stakeholders Disengage (and How to Fix Each One)
While we're at it, let's deal with engagement, because that's a huge problem too. Remember, the sprint review is a review of the sprint, not a sprint demo. It's an honest look at what's getting in our way and what's helping us, because sometimes stakeholders can be great advocates for removing impediments. The demo matters, but how we're tracking as a whole matters just as much. When will the work be done? How much are we looking at? What does the budget look like? That status conversation is part of what stakeholders actually want.
Stakeholders tend to disengage for one of four reasons, and the fix for each is a little different.
If they disengage because no decision is ever made, build the decision moment into the meeting and make sure they're the ones making it.
If they disengage because the demo is too technical, show outcomes and customer behavior instead of code and screens. Translate it. I still think the code matters, because we want other developers to look at it and push back, so don't strip the technical content entirely. Just build a bridge for the people who need one.
If they disengage because the work doesn't connect to anything they care about, fix the outcome statement at the top of the review. They should hear their goal in your opening sentence. And if they're never in the room at all, maybe the product owner isn't inviting the right stakeholders.
If they disengage because previous feedback was ignored, open the next review by naming what they said last time and what you did about it. People start to feel their requests are going into a black hole. Even if the answer is "we considered it and chose not to act, and here's why," that is an engagement-repair item.
And if a stakeholder still won't engage after all that, don't chase them. Ask them privately what they'd need to see to make the session worth their time. Sometimes the answer is, "It's just not my decision to make." That tells you the wrong person is in the room. Go find the right one.
The One Thing to Try Before Your Next Review
Turn the decision test into a checklist the Scrum Master can enforce. It's a contract the room makes with itself: outcomes, evidence, decision. Run those three questions until it feels normal, and then run them some more. Getting out of the demo rut takes time.
I don't want the sprint goal in story-point language. I want the outcome in behavioral language, in plain words. A simple sprint review agenda helps here too, because it gives everyone a breadcrumb trail and a consistent sense of what to expect. Walk through the work inside that frame. Do the demonstration, but do it inside that frame.
You'll probably get pushback the first time, because somebody came expecting a demo. That's fine. The discomfort of change is the point.
Trading Rehearsal for Honesty
What you're really doing is trading rehearsal for honesty, and honesty is what builds trust between the product team and the business it serves. It isn't easy.
So remember: a sprint review is not a show. It's the moment your team and your business look at reality together and decide what to do next. It's okay to look at the product backlog and change it. If it isn't that, then it's theater, and that movie is expensive. I can promise you that.
If you're practicing Scrum, the sprint review is sometimes a joke, let's be honest. And if you're not practicing Scrum, that's okay too. The question is the same either way: what are you using to show your stakeholders what you've built so you can make better decisions together?
If you want help building a sprint review that actually drives decisions, that's exactly the kind of thing we coach teams and leaders through at Big Agile. Take a look at our classes and coaching programs and find the one that fits where your team is right now.