The sprint review is the most forgivable meeting to kill. Planning needs real-time negotiation. Retros need candor that’s easier face to face. But review is a demo — and demos survive being asynchronous better than almost anything else on the calendar.
We moved our reviews async six months ago. Attendance-by-viewing went up, stakeholders actually read the thing, and we got an hour a fortnight back. Here’s the exact format, including the parts that nearly broke it.
The format
Every review is one written document with three sections, posted at the end of the sprint:
1. Shipped. One entry per item, two sentences max: what it is, and where to see it. Link the merged PR, the staging URL, or a 60-second screen recording. If there’s nothing to link, it didn’t ship — it goes in section three. This rule is the whole game. “Almost done” is not a demo.
2. Metrics that moved. Three numbers, not thirty. For us: activation rate, p95 of the action users do most, and weekly retention. If nothing moved, write “nothing moved” and say why. Stakeholders trust a review that admits flat weeks.
3. Carried over. Every unfinished item, named, with one line on why. No shame — just a public record. Two sprints of the same item appearing here is a planning problem, and now it’s visible.
The 24-hour window
Post the review at sprint end, then leave a 24-hour comment window. Reactions and questions happen in the thread. Questions that need discussion get their own thread or a 15-minute call — scheduled only if someone asks. Most weeks, nobody asks.
The window matters more than the document. Without it, async review becomes a message in a bottle. With it, the sales lead asks the question she’d never have raised in a room of engineers, and that question is usually the useful one.
The 24-hour window, basically.
The rules that keep it alive
- The author rotates. The person who writes it learns the sprint differently. Also, one voice writing every review becomes a PR department.
- Two sentences per shipped item. The moment entries become essays, people stop reading and you’ve reinvented the status report.
- Never carry a third time. An item in “carried over” for a third sprint gets automatically re-scoped in planning. This is the forcing function the meeting used to provide by social pressure.
What you lose
Be honest: you lose the energy of a live demo, and for genuinely visual work — a new interaction, a redesigned flow — a screen recording is a weaker hit than watching someone click through it. When we ship something like that, we book 20 minutes and demo it live. Async is the default, not a religion.
You also lose the ambient signal of watching stakeholders react. You can get some of it back by actually reading the comments and saying the quiet part out loud in the next review: “Nobody commented on the onboarding change, so here’s what happened to the numbers instead.”
Getting started this week
End your current sprint with the three-section document above. Give it 24 hours. If the thread goes silent, don’t declare failure — ask one specific person one specific question in it. That’s usually enough to prove the channel works.
We build Kahoona around exactly this kind of artifact: the board, the PRs, and the written record in one workspace, so the sprint review practically writes itself from what already shipped.
👉 See what your team actually shipped this sprint — Kahoona is free to start: kahoona.app
Related: How to Run Async Standups From Your GitHub Activity · The Standup Is a Latency Problem