Too many sprint reviews include following a scripted presentation: “Story 1247: As a user, I want to filter the product list. Story 1248: As a user, I want to sort by price. Story 1249: As a user, I want to save my search preferences.”
The stakeholders are polite. They nod. But one can see their eyes glaze over.
Instead of showing and telling stories, a laundry list is recited.
Stakeholders Don’t Care About Ticket Numbers
Stakeholders don’t think in user stories. They think in problems and solutions. They think in terms of their customers, their market, and their business goals.
When we walk into a sprint review and start reciting story IDs and acceptance criteria, we’re speaking a language that doesn’t resonate with them.
They don’t care that we completed Story 1247. They care that buyers can now find products faster during peak season, which means fewer abandoned carts and more revenue.
That’s the story we need to tell.
Flip the User Story Format
Traditional user stories follow this format: “As a [role], I want [feature] so that [benefit].”
It’s functional. It works for planning. But it buries the most important part at the end.
So we flip the story: “In order to [value], as a [role] I want [feature].”
Start with the why. Lead with the business value or customer impact. Then show what we built.
If I can’t articulate why a feature matters in plain English, I probably shouldn’t be writing the code yet. And if I can articulate it, that’s the story I should be telling in the sprint review.
Craft a Story Arc
Instead of walking through individual stories one by one, I look for the thread that connects them.
Let’s say we built three features this sprint:
-
A filter for the product list
-
A sort-by-price option
-
A way to save search preferences
Those aren’t three separate stories. They’re one story: “We made it easier for buyers to find what they need and come back to it later.”
Now I can tell it like this:
“We heard from buyers that they were frustrated during peak season. They’d search for products, get interrupted, and have to start over. So this sprint, we focused on making the search faster and more persistent. Now they can filter, sort, and save their preferences. Early feedback says it’s cutting their search time in half.”
That’s a story. It has a problem, a solution, and an outcome. It connects to real people and real business impact.
If You Can’t Explain the Value, Don’t Write the Code
This is something I tell developers all the time: if you can’t explain why a feature is valuable in plain English, you’re not ready to implement it.
Not because you’re not smart enough. But if you don’t understand the value, how will you make good decisions when you hit edge cases? How will you know what to prioritize when you’re running out of time?
And more importantly, how will you help stakeholders understand what you built and why it matters?
Learning to talk about work in terms of value, not just functionality, makes you a better developer. It also makes sprint reviews more meaningful.
From “I Added an API Endpoint” to “Now Buyers Can…”
Imagine a developer has just finished a feature, and you ask them to walk through it for the sprint review.
They might say, “I added a new API endpoint that returns inventory data in real time.”
You ask, “Okay, but what does that mean for the people using the system?”
They pause. Then they say, “Now buyers can see real-time inventory from their mobile devices, so they don’t have to call the warehouse.”
That’s the version that should go in the sprint review.
It’s not about “dumbing it down” (an expression I’ve heard from developers before, and it makes my skin crawl). It’s about connecting the technical work to the human impact. Stakeholders need to hear the second version. And honestly, developers benefit from practicing it.
The Story Connects the Work to the World
At the end of the day, a sprint review is not a technical demo. It’s a conversation about whether what we’re building moves us closer to the desired outcome.
When we tell a story rather than read a list, we give stakeholders something to react to. They can ask questions. They can share what surprised them. They can connect what we built to market conditions or customer feedback we didn’t have.
That feedback feeds back into the product backlog. It shapes what we build next.
But if we just recite ticket numbers, we don’t create space for that conversation.
A Small Shift in How We Present
This doesn’t require a massive change. It’s a shift in how we prepare and present.
Before the sprint review, I ask, “What’s the thread? What problem were we solving? What value did we deliver?”
Then I built the presentation and conversation around that story, not around the backlog items.
It takes a little more thought. But it makes the sprint review more engaging, more collaborative, and more valuable for everyone in the room.
What story are you telling in your next sprint review?
Leave a Reply