Home → Part 06
Sprint Review: A Feedback Loop, Not a Demo Show
If nobody suggests a change, nobody is listening. In a sprint review, applause is not a good signal; an objection is.
- Feedback beats applause. Silence is the most dangerous signal — it means disinterest or lost trust.
- Make the stakeholder part of the process. Anyone who is not part of the process will be against the outcome.
- No polished demos. Show working software with its rough edges; a rehearsed show hides reality.
- If the backlog did not change, there was no review. Its output is a revised backlog.
What it is, what it is not
A working session to inspect the increment, adapt the backlog based on real feedback, and make the stakeholder a co-owner of the product.
A polished demo show, a status report to management, or a ceremony to celebrate the end of the sprint.
The simplest way to tell them apart: when the meeting ended, did anything in the backlog change? If not, what you held was a demo.
Why you have to bring the stakeholder inside
A stakeholder who is kept out of the build process takes the critic's seat at delivery. That is not bad faith, it is human nature. But the same person, seeing working software every two weeks, giving feedback, and watching that feedback land in the next sprint, is no longer a critic — they are a co-builder.
There is a well-known effect behind this: people attach disproportionate value to things they helped create. The sprint review is the mechanism that triggers it. For that sense of contribution to be real, the stakeholder's input has to actually change something — a ceremonial "any thoughts?" does not produce it.
Three reasons fast feedback matters
- Cost. Correcting a wrong decision after two weeks is cheap; after two months it burns the budget.
- Enthusiasm. A stakeholder who sees concrete progress turns into support. One who does not, you have to win over with slide decks.
- Shared responsibility. A stakeholder who approved it in the review cannot say "this is not what I asked for" at delivery.
Suggested agenda — 60 minutes
| Time | Section | Content |
|---|---|---|
| 5 min | Context | What was the sprint goal? Which business problem did we set out to solve? |
| 10 min | What was delivered | A high-level summary of completed items. A map before diving into demos. |
| 20 min | Live demo | Working software. Let stakeholders click it themselves; encourage questions mid-demo. |
| 15 min | Feedback | What should change, what is missing? If there is silence, ask direct questions. |
| 10 min | Backlog implications | What is added, re-prioritised or removed? |
The last ten minutes are not negotiable. If that is the section you drop, the meeting has turned back into a demo.
The right attendees
Inviting everyone reduces participation. Three groups are enough:
- People who can give feedback: users and domain experts who know the problem space.
- People who can decide: stakeholders who can approve a change of direction or priority.
- People who need to know: dependent teams and relevant leadership.
My own rule: if the "need to know" group outnumbers the other two combined, the meeting turns into a presentation. When that happens, send them a written summary separately and keep the review small.
Getting real feedback
This is the hardest part. Stakeholders usually retreat into polite approval: "looks good, well done." That sentence carries no information. Stop asking closed questions:
- "What surprised you about what you just saw?"
- "If you could change one thing, what would it be?"
- "Would you use this as it is today, or is something missing?"
- "What would make this more useful?"
- "Based on what you have seen, what should we build next?"
A practical way to handle silence: instead of asking the room and waiting, ask a specific person a specific question. "Ayşe, your call centre team will open this screen forty times a day — does the flow make sense to you?" A question with an address does not go unanswered.
Common mistakes
- Demo theatre: hours of rehearsal, scenarios that hide the rough edges.
- No stakeholders: only the team in the room, no feedback produced.
- Cancelling because nothing finished: "nothing is done, let us skip it."
- Backlog never changes: feedback is collected and nothing happens.
- Show it unrehearsed; name the gaps out loud
- If stakeholders stop coming, find out why — it is a trust signal
- Show work in progress and get early feedback
- Tie every piece of feedback to a backlog item and show the decision there
Measuring whether the review works
| Signal | Good | Bad |
|---|---|---|
| Stakeholder participation | Key stakeholders present and talking | Empty room or only the team |
| Feedback produced | Several actionable insights | Polite nodding, no objections |
| Backlog change | Items added or re-prioritised | Backlog unchanged |
| Stakeholder enthusiasm | "When can we use this?" | Passive watching, early exit |
Checklist
- Was the sprint goal restated at the start?
- Was working software shown (not slides)?
- Did a stakeholder touch the screen themselves?
- Was at least one person asked a question by name?
- Was the feedback turned into backlog items?
- Were the reasons given for feedback that was rejected?
Conclusion
The sprint review is your chance to close the feedback loop every two weeks. But its real power is not the feedback, it is the ownership it creates. Invite the right people, show the real work, ask the hard questions, and change the backlog based on what you learned.
The alternative is building in a vacuum. Products built in a vacuum collapse at first contact with reality.
The "not part of it, against it" principle, the 60-minute agenda and the feedback questions are adapted from İbrahim Demir's Sprint Review post. The attendee-balance rule and the "question with an address" technique are my additions. Marty Cagan's Inspired and Teresa Torres's Continuous Discovery Habits are good follow-up reads.