Sprint Review

When the end of a cycle is reported as completion marks and documents, the person who asked for the work can't tell whether it matches what they pictured. The word "done" is identical while the screens in two heads are not. That gap usually surfaces weeks later, when someone finally sees the real screen — by which point the team is already halfway through the next cycle.

At Pagedeck the gap once reached a customer. Theo added filters to the document list and marked it done, and Sofia told a customer evaluating the product that it was ready. Two weeks later the customer tried it and found no way to filter by date range. The request had said only "filters," and Theo had built filtering by status. Neither of them had been wrong about the word; the word had been doing two jobs.

A sprint review pulls that verification forward to the end of the cycle. Instead of reporting in words, the screen gets driven live. It's where the meaning of "done" gets aligned through behavior, and the value it produces is that a mismatch costs two weeks rather than a quarter. The shorter the cycle, the smaller the thing that can go wrong unnoticed.

Run what was built and take input on the spot. Six steps.

1. Prepare only what works. Use a live screen rather than slides. It has to run in an environment like production; a screen dressed with development data hides what actually works. If it can't be shown, that fact is already this cycle's result.
2. Read the cycle's goal again. Reading aloud the one sentence set at sprint planning fixes both the order of the demo and the standard for judging it.
3. Demo item by item, with the person who built it driving. Items that didn't meet the completion criteria aren't shown as done. Break that rule and the meeting loses its credibility from the next cycle onward. Nobody attends a session where the demos don't reflect the state of the product.
4. State what didn't finish first. Putting committed-but-missing items and their reasons up front changes the questions asked about everything after. Held to the end, it reads as being caught out.
5. Record input in two columns: what gets decided now and what comes back later. Write down the input that was declined as declined. Input that goes unrecorded gets repeated by the same person next time. The declined column is also what keeps the candidate list from growing without bound.
6. Feed the input into the next cycle's candidate list. This meeting is not a report; it's the input device that updates that list. Input that never reaches the list produces the same comment at the next session.

For a two-week cycle, keep it under an hour. Needing longer can mean the items were sliced too finely. It can also mean the demo is being narrated rather than driven.

It's held on the last day of the cycle, with the team plus the people who care about the result.

Attendance reaches outside the team. At Pagedeck that means Sofia, who knows what customers asked, Grace, who makes the business calls, and Noa, who designed the screens. Some teams invite customers directly, which produces the most accurate input and raises the cost of choosing what to show. Either way the attendance list is a decision, not an invitation sent to everyone.

The person who built it demos it. Put a stand-in at the keyboard and the answers stall as soon as a question goes slightly deeper, at which point the meeting becomes delivery rather than verification. When several sessions run with nobody from outside the team attending, this slot hardens into an internal status report.

The timing is before the retrospective. What was built comes first, then how the work went. Reverse the order and the session about working methods fills up with result talk again. One order, every cycle, is what makes both sessions habitual.

It differs from daily scrum in who it's for. The short daily check aligns plan and reality inside the team; this meeting verifies the result from outside it. Teams on a one-week sprint sometimes hold it only every second cycle because there's less to show. Even then, the step of stating what didn't finish stays in every cycle. Skipping it is how a review turns into a highlight reel.

"Show the screen, not slides. If something doesn't work, say it doesn't work."

This is a session for verifying behavior.

"This didn't meet the completion criteria, so I'll show it next cycle."

Refusing to blur the meaning of done inside the meeting.

"Two of these go on the next cycle's candidate list and one I'm declining here."

Separating collecting input from acting on it.

At Pagedeck's first session Theo demoed the filters. Watching the screen, Sofia said there was no field for filtering by date range. Theo explained why he had built status filtering and put date range on the candidate list for the next cycle.

Previously the same problem had arrived through a customer with two weeks already gone. This time the gap shrank to one hour of meeting. It also became visible that one word, "filters," had meant two different screens to two people, and from then on requests spell out the criteria to filter by as separate items. Mia put date range into the next cycle's goal sentence on the spot.

The most common reading is that it's a presentation, because gathering people to show screens looks like one. But the purpose here is collecting information, not getting approval. Show only the parts that went well and the meeting ends smoothly with nothing gained. Showing what didn't finish and what finished ambiguously is what produces the next cycle's work in the room. Silence from the attendees is a result worth investigating rather than a pass. A meeting that ran smoothly is not itself an outcome.

Reading it as the same session as the retrospective is the other one, since both happen at the end of a cycle. What they examine differs. This one looks at the result and decides what to build next; a retrospective looks at how the work went and decides how to work. Merge them and result talk consumes the time while the method talk never happens. Held back to back, keeping the two time boxes separate works better.