The Sprint Review Isn't the Feedback Loop

Every sprint in a project I worked on ended with a stakeholder review. I would demonstrate the features shipped that sprint. The stakeholders would confirm they worked. Occasionally someone asked a question. The session would end and I would plan the next sprint based on what had been confirmed.

The sprint reviews were not where the useful feedback came from.

The Pattern I Noticed

About halfway through the project, I looked back at the changes that had most substantially improved the system. Almost none of them had originated in a sprint review. They came from a message a few days after the review. A passing comment when someone was using the system for something real. A note raised mid-sprint because an operator had tried to do something and found the system didn't support it the way they expected.

Three changes in particular stand out. An edge case that nobody had documented during requirements gathering, surfaced informally when an operator encountered it while testing against real data. A workflow redesign that came from a brief message explaining that the way I had structured a particular interaction didn't match how the operator actually thought about the task. A shortcut feature suggested in a casual aside that turned out to be one of the things operators valued most in the finished system.

None of these came through the structured sprint review. All of them came through channels with lower stakes.

Why Sprint Reviews Produce the Wrong Signal

The sprint review is not a natural environment for surfacing uncertainty. It's a presentation: the developer has prepared something to show, the stakeholder is there to evaluate it, and the implicit social contract is that this is a checkpoint, a moment of confirmation or redirection rather than an open exploration.

This shapes what people say.

A stakeholder in a formal review will raise concerns they have thought through: concerns they can articulate clearly, concerns that feel substantial enough to justify interrupting a structured session. They will not, generally, raise a vague unease about a workflow they haven't fully thought through yet. They will not flag a minor inconsistency they noticed while doing something else. They will not surface the thing that is a bit wrong but they are not sure how to describe.

These are exactly the signals that matter most in early-stage product development: the things people notice but don't say in a formal setting, the half-formed observations that haven't yet resolved into a proper complaint, the edge cases that emerge from use rather than from hypothetical review. A formal review tells you what people decided to say. The informal correction tells you what they noticed.

Why the Low-Stakes Channel Works

The asynchronous message works because it removes the performance element from the exchange. The stakeholder isn't in a meeting, nobody is waiting on their response, and there's no implicit pressure to have thought it through. They can say "this is probably nothing, but I noticed that..." and the message is complete. That conversational register is not available in a formal review.

It also decouples the timing of feedback from the review cadence. Sprint reviews happen every two or three weeks. An operator who hits a problem on a Tuesday doesn't file it away for the Thursday review, they send a message, and the feedback arrives while they can still describe exactly what they were doing and what felt wrong.

The three changes above were precisely the kind of correction that a specification-first approach would have missed. They arose from real use, in real contexts, often at the edges of the documented requirements. No amount of upfront requirements-gathering would have surfaced them. They emerged from iteration, and the iteration was made useful by the informal channel, not the formal one.

What the Sprint Review Is For

This is not an argument against sprint reviews. They serve a real function: demonstrating that committed work was delivered, confirming that the direction is correct at a structural level, and giving stakeholders a regular touchpoint for higher-level planning.

What they don't do is substitute for the informal channel. The sprint review is the formal record; the asynchronous message is where the feedback loop actually runs.

Running one without the other leaves you with either undocumented direction (informal only) or a false confidence that the sprint review captures everything worth capturing (formal only). The formal ceremony creates the conditions in which stakeholders feel engaged. That engagement is what makes them send the message at nine on a Wednesday that tells you the thing you need to change.

Optimising for ceremonies optimises for the signal people are willing to produce in a formal setting. Optimising for the informal channel optimises for the signal they produce when the cost of saying something half-formed is low, which is where the workflow redesign and the shortcut feature both came from.