There is a meeting that happens at the end of every sprint in almost every engineering organization that runs Agile. It is called the sprint review. It is supposed to be where the team demonstrates what they built, gets feedback from stakeholders, and connects the work to the outcomes the business cares about.
In practice, it is usually a show-and-tell where engineers describe their tickets to people who would rather be somewhere else.
You can tell within the first two minutes whether a sprint review is going to be useful. If the person presenting hasn’t planned what they’re going to say, the meeting spirals quickly into narration. Someone opens a ticket. They explain what it does. They show a screenshot. They move to the next ticket. Words accumulate. Time passes. Nobody in the room — including the people who built the thing — can clearly articulate what value was just delivered.
The business partners sitting across the table learn something from that meeting. They learn that sprint reviews are where you go to watch engineers describe their work. Not where the needle moves. Not where decisions get made. Just a ceremony they have to attend.
That is not a sprint review problem. It is a preparation problem. And the preparation problem is actually a thinking problem — because a team that cannot prepare a clear sprint review is a team that has not clearly defined what value they were trying to deliver in the first place.
Start With the Hypothesis
The most important thing that happens in a well-run sprint review happens before the meeting starts.
Someone on the team — ideally the engineer who did the work, supported by the PM — should be able to complete this sentence before the review begins:
“We believed that if we did X, we would see Y — and here is why we believed that.”
That sentence is the spine of the entire presentation. Everything else hangs off it.
Here is a concrete example of what this looks like in practice. A team working on API reliability identifies that a significant number of failed requests are transient — the kind of failure that would succeed if tried again. They form a hypothesis: if we retry failed API requests up to three times within a ten-second window, we will increase the number of successful responses by at least 25%.
That hypothesis does several things at once. It tells the stakeholder what problem the team was solving. It gives them a number to react to — 25% is either meaningful or it isn’t, and the stakeholder probably knows which. It sets up the rest of the presentation as a test of a specific claim rather than a tour of completed work.
Start here. Every sprint review should open with the hypothesis. What did we believe, what were we trying to prove, and why did we think it mattered?
Then Show What You Observed
After the hypothesis comes the evidence.
What did you actually find? Did the metric move the way you expected? More? Less? In a direction you didn’t anticipate?
This is where the sprint review becomes a real conversation rather than a presentation. A number that moved the way you expected is a confirmation — the hypothesis held, the approach worked, here is what we want to try next. A number that moved less than expected is a signal — something about the assumption was wrong, and now you have real data to figure out what. A number that moved in an unexpected direction is the most interesting outcome of all — it means you learned something you didn’t know you were going to learn.
Business partners do not come to sprint reviews to watch engineers demonstrate features. They come because they care about outcomes — whether the product is moving in the right direction, whether the investment is producing results, whether the decisions they made six weeks ago are holding up. The evidence section is the only part of the sprint review that speaks directly to those questions.
Name the number. Show where it was at the start of the sprint. Show where it is now. Let the room react.
Then Explain the How
Only after the hypothesis and the evidence do you show what you built.
This is the inversion most sprint reviews get wrong. They start with the how — here is what we built, here is how it works, here is a demo — and treat the outcome as an afterthought, if it gets mentioned at all. The result is a presentation that answers a question nobody was asking: how does this work? Instead of the question everyone in the room actually has: did it work?
When you lead with the hypothesis and the evidence, the how becomes the explanation of the method rather than the point of the meeting. You built the retry logic because you believed transient failures were recoverable. Here is how it works. Here is what the implementation looks like. Here is what we had to navigate to get it there.
The how section is where the engineers get to show their craft. But it lands differently when the audience already knows the outcome. They are not watching a demo and wondering whether it matters. They already know it matters — they just saw the number — and now they are watching to understand how you got there.
Name the Caveats Before Someone Else Does
There is a moment in almost every sprint review demo that derails the conversation. It is not a technical problem. It is a test data problem.
A stakeholder notices something on the screen that looks wrong. Account X has a negative balance. The timestamp is from 2019. The user’s name is “Test User 47.” They raise it. The engineer explains it. Five minutes disappear. The thread of the presentation is lost and it takes another five minutes to get it back.
This is entirely preventable.
Before the demo, identify everything in the test environment that might look wrong to someone who doesn’t know your data setup. Name it explicitly at the start of the demo section, before anyone has a chance to notice it themselves:
“You’ll notice that some accounts in this environment have negative balances — that’s an artifact of how our test data is structured, not a bug in the feature we’re showing. I wanted to flag it so it doesn’t distract from what we’re demonstrating.”
That one sentence does three things. It shows you prepared. It preempts the distraction. And it signals to the stakeholder that you have thought carefully about what they are going to see — which is exactly the kind of attention to detail that builds trust over time.
Name the caveats before someone else finds them for you.
The Structure That Works
A sprint review that does its job follows a simple four-part structure:
The hypothesis What did we believe, what were we trying to prove, and why did we think it mattered? One or two sentences. This is where you orient the room before anything else happens.
The evidence What did we observe? Show the number. Show where it was, show where it is, let the room react. This is the most important part of the meeting and it should happen early.
The how What did we build? How does it work? This is the demo section — but it comes after the outcome, not before it.
The caveats What might look wrong in the demo that isn’t actually wrong? Name it before someone finds it.
That structure takes no more time than the narration format most teams default to. It takes more preparation — someone has to think carefully about the hypothesis before the meeting, and someone has to know the evidence before they walk into the room. But that preparation is the point. A team that cannot prepare a sprint review in this format is a team that has not done the thinking that should precede the demo.
The sprint review is not the problem. It is the diagnostic.
What to Do Before Your Next One
Before your next sprint review, ask the team one question:
“What did we believe at the start of this sprint, and what did we learn?”
If nobody can answer it, the review is going to be a narration. The work may have been done well. The value is invisible.
If someone can answer it — if there is a hypothesis and a result and a team that understands the connection between the two — you have a sprint review worth running.
The preparation takes fifteen minutes. The difference in the room is everything.
If this resonated, the thinking behind it goes deeper in my book — Getting Engineers to Give a Damn: A Manager's Guide to Building Ownership Inside Broken Systems. Written for managers inside large, constrained organizations who are tired of sprint reviews that go nowhere.
Top comments (0)