I used to walk into sprint reviews with my memory as the only backup. I would scan the board, hope someone else remembered the details, and try to string together a demo on the spot. Sometimes it worked. More often it felt like we were asking stakeholders to trust us that we had been busy.
That changed when I started using the same notes I was already taking during the sprint to build the review and the retro. The notes helped me remember what we did, but they also helped me tell a better story.
The Review Outline
The heart of the change is a review outline. By the Thursday before the review, I sit down with my sprint note and outline what we are going to show and, most importantly, have conversations about. It is a short document with a few sections, not a slide deck.
- The sprint goal and the main achievements.
- The sequence of things we will show.
- The images, screenshots, or videos we will use.
- The places where we will stop and ask for feedback.
- The questions we want stakeholders to answer.
For example, a recent script looked like this:
- Show the new contract validation in action, then ask: “Is this the right level of strictness?”
- Walk through the dashboard widget with a screenshot of real data.
- Play a 30-second setup video for the complex workflow, then pause for feedback on the new steps.
- Close with the roadmap.
That script becomes the backbone of the review. It keeps us from rambling. It keeps the demo focused on value. Most importantly, it keeps the stakeholders from having to guess why any of this matters.
I wrote about this in designing the sprint review experience. A sprint review is a conversation, not a status report. The outline is the invitation. It tells the stakeholders what we are going to show, what we need from them, and where the conversation should land.
A Story, Not a List of Stories
The biggest mistake I used to make was walking through the user stories one by one. The stakeholders do not care about the boundaries we drew around the work. They care about what the work does for them.
This is where user stories become story arcs. We might have completed three stories to deliver one feature. The demo should show the feature. The story boundaries are an implementation detail. The value is the narrative.
I build that narrative in the script. We show the starting state, the action, and the result. We use screenshots or short videos for the parts that are hard to set up live. We order the demos so each one builds on the last. By the end of the review, the stakeholders can see the whole shape of the sprint, not just the pieces.
The Pre-Review Walkthrough
I do not wait until Friday to test the script. The day before, the team walks through it together. We show the images, we run the demos, we time the transitions. The product owner watches. If something feels off, we fix it then.
That walkthrough almost always surfaces improvements. The order is wrong. A demo needs a setup video because the live data takes too long to create. We forgot to ask about a specific scenario. Somebody suggests a screenshot that shows the context better. We write all of that down in the sprint note.
The result is that by the time the actual review starts, we have already ironed out the awkward parts. The team is confident. The presenter knows the story. The stakeholders get a polished experience instead of a live debugging session.
Capturing the Room
During the review, the notes continue. I write down the main feedback as it comes. I also write down the reactions. Sometimes a stakeholder lights up mid-sentence. Sometimes they look confused. Sometimes they say something like, “Get out of here, you built that?” Those reactions are data. They tell us what landed and what did not.
I ask the team to help capture this. The person presenting cannot also watch every face. The rest of the team should be paying attention to body language and writing down what they see. This is the team’s job, not the product owner’s or the business analyst’s. The closer the whole team is to the feedback, the better the next sprint will be.
We also capture the requests that come up. “Does this also handle this scenario?” “Could we adjust this behavior?” Those questions belong in the backlog conversation, and they should not depend on one person’s memory of what was said.
Retro as a Living Section
This is also why the retro comes after the review. The reason is simple: the review gives us real data to inspect. The retro is where we adapt based on that data.
But I do not start the retro section empty. I start filling it the day the sprint begins. When something goes well, I write it down. When a tool slows us down, I write it down. When somebody does something worth praising, I write it down. By the time Friday arrives, the retro is not a blank page. It is a collection of observations we made throughout the sprint.
That habit removes the scramble. Nobody has to sit in the retro room trying to remember what annoyed them two weeks ago. The notes are right there. We can move straight to discussion and action.
Next Actions That Stick
The retro should produce next actions. Not just complaints. Real things we will try before the next sprint ends.
I like to split them into a few categories. People highlights: who did something worth recognizing. Process highlights: what worked and should stay. Tool or technique experiments: what we want to try. Sprint review improvements: what we can do next time to make the conversation more engaging and the demo clearer.
That last category is one of my favorites. The retro becomes a way to make the next review better. Maybe we need a one-minute setup video. Maybe we should flip the order of the demos. Maybe one of the developers should explain a technical concept in plain language for five minutes at the end because the stakeholders loved it this time. Those improvements compound.
Lessons Learned
Many of the teams I work with run a separate lessons-learned session. This is where the notes from the sprint turn into shared knowledge. Somebody shows how they solved the validation problem. Somebody shares a helpful article. Somebody explains an epiphany they had about the domain.
These sessions work because the notes are already there. The person sharing does not have to reconstruct the problem from memory. They can point to the note, the screenshot, the snippet. The team can ask questions. The knowledge stays in the team instead of living in one person’s head.
The Payoff
When the review and the retro are built from notes instead of memory, the whole team operates differently. The demo is sharper. The feedback is captured. The retro is actionable. The lessons are shared.
Most importantly, the sprint becomes inspectable. We can look back and see not just what we shipped, but what we learned, what we promised, and what we should do differently next time. That is the real value of documentation. The clarity, not the archive.
In the next post I will describe how those same notes become career capital. The work that feeds the team can also feed your own growth.
A good review is a conversation the team prepared to have, not a performance.
Leave a Reply