Guide
How to run an async sprint review
In an async sprint review, the team posts short recorded demos instead of presenting in a meeting. Stakeholders watch when it suits them and comment by a set date, and what they say shapes the next sprint. This guide covers when to do it, how to record a demo worth watching, what to ask, and how to turn the answers into tickets.
Updated
Before you start
When an async sprint review works, and when to meet
The sprint review is where people outside the team see what was built and say what should change. Async keeps that without finding a slot for everyone. It suits most sprints, but not all of them.
Go async when
Your stakeholders can’t all make one slot
They’re in other time zones, or their calendars are full of customer calls. Async lets each of them watch at a time that works.
The work can be shown on screen
A new screen, a changed flow, a report or an API response. If you can show it working, you can record it.
Most people care about one or two items
In a meeting, sales sits through the database migration to see the pricing page. With a demo for each item, people watch only the ones that matter to them.
You want the feedback in writing
A comment on a recording stays tied to what it’s about, and can link to a ticket. What’s said in a meeting depends on someone’s notes.
Meet live when
A decision needs back-and-forth
Changing the scope, the priorities or the product goal takes the kind of discussion a comment thread does badly.
The sprint missed its goal
When something went wrong, people want to ask questions and hear the answers. Explain it live, and keep the demos for the work that’s done.
There’s little to see
A database migration, a research spike or infrastructure work is easier to explain in a conversation than to show in a recording.
Your stakeholders are new to the team
Meet a few times first, so they know the team and the kind of feedback that helps. Then move the demos to async.
Or do both: post the demos async, then keep 15 minutes live for the decisions. The meeting is short, because the demos and the first reactions happen before it.
Step by step
How to run an async sprint review in six steps
Start a few days before the sprint ends, so the feedback is in before you plan the next one.
Step 1
Choose who reviews each piece of work
Not everyone needs to see everything. For each feature or fix, pick the people who will sell it, support it, design around it or decide on it, and name the one person whose answer you can’t ship without. A short list of the right people gives more feedback than a long list of everyone.
In Circlebak · Add them as stakeholders of the demo. Stakeholders of its collection are emailed about every new demo there too, so nobody has to remember to invite them.
Step 2
Set a feedback deadline
Without a date, async feedback trickles in for weeks or never comes. Choose the date when you post, put it at the top of the description and stick to it. Two working days suits most teams: long enough for other time zones and busy weeks, and short enough to land before sprint planning. Anything that comes in later goes to the backlog like any other request.
In Circlebak · Set the date when you upload. A day before it, stakeholders who haven’t commented yet get a reminder email, so you don’t have to chase them.
Step 3
Record one short demo per piece of work
Record each feature or fix on its own, in three to five minutes, showing the real product. People watch the parts they care about, and you get feedback on each part separately. If a demo runs past five minutes, it’s usually two demos. How to record a good demo has the structure and the tips.
In Circlebak · Circlebak doesn’t record. Use the recorder you already have, and upload the file: MP4, MOV, WebM or MKV, up to 5 GB.
Step 4
Post it with specific questions
“Any feedback?” gets silence or nitpicks. Give the demo a title that says what changed, then write the goal, what’s done and what isn’t, and two or three questions only your stakeholders can answer. Ask reviewers to comment on the moment they mean, so “this is confusing” points at what’s confusing.
In Circlebak · Comments are pinned to the second they’re about. @mention the person whose answer you need, and they get an email.
Step 5
Reply, then turn comments into tickets
Reply to every comment, even if only to say you’ve seen it, so reviewers know it was worth their time. Then sort each one: change it this sprint, ticket it for later, or leave it, and say why. For anything that becomes work, create the ticket in your tracker and link it from the comment, so whoever raised it can follow it there. Resolve the thread once it’s handled.
In Circlebak · Paste the ticket’s link on the comment. Circlebak recognizes Jira, Linear, GitHub, GitLab, Azure DevOps and Asana, and any other link works too. Nothing syncs, so there’s nothing to install.
Step 6
Close the loop
When the deadline passes, tell everyone who took part what you heard, what changes and what was ticketed. Take the open questions to sprint planning, or to a short live meeting if they need a decision. Stakeholders who see their feedback used keep giving it.
In Circlebak · Resolved threads show what’s been handled, and each linked comment leads to its ticket.
Recording
How to record a good 3–5 minute demo
A demo isn’t a presentation. Show the product working, say why it matters, and end with what you need from the people watching.
0:00
The goal
One sentence on the problem this solves, and for whom.
0:30
Show it working
Walk through the real flow with realistic data, the way a customer would use it.
3:30
What isn’t done
Name what’s missing, faked or still changing, so nobody spends a comment on it.
4:00
Your questions
Ask the two or three questions you need answered, and say by when.
Close what isn’t part of the demo
Turn on Do Not Disturb, close other tabs and windows, and use realistic data rather than “test 123”.
Make the text easy to read
Record one window rather than a large screen, and zoom the browser to 125% or more, so people can read it on a laptop.
Talk it through, don’t read a script
Say what you’re doing and why, as you would to a colleague beside you. A few notes are enough.
Get the sound right
Bad sound is harder to sit through than a rough picture. A quiet room and a headset microphone are enough.
Show what happens when it goes wrong
An error, an empty list or a missing permission. Sales and support will ask about these, so show them first.
Skip the editing
One take with a small stumble is fine. If you lose your place, pause and carry on, or record that part again.
Template
Async sprint review template
Copy these into your demo’s description, your tracker or wherever you post. Replace the brackets, and keep only the questions that apply.
The demo post
The title and description reviewers read before they press play.
[What changed, in a few words] Goal: [the problem this solves, and for whom] In this demo - [What you show, and where it starts, like 0:30] - Done: [what works now] - Not done yet: [what’s missing, faked or still changing] Questions for you 1. [A question only stakeholders can answer] 2. [A choice you need them to make] Feedback by [day and date]. Anything later goes to the backlog. Tickets: [link to the epic or tickets]
Questions for reviewers
Pick two or three for each demo. Specific questions get specific answers.
Does this solve the problem it was meant to solve? If not, what’s missing? What would stop you from selling, supporting or using this on launch day? What did you expect to see that isn’t here? Is anything confusing enough that a customer would ask about it? Which option should we ship, A or B, and why? Who else should see this before it ships?
A note for the first async review
Send it to your stakeholders before the first one, so they know what to expect.
This sprint’s review is async. Instead of the meeting, each team will post a short demo of what it built, 3 to 5 minutes each, by [day]. Watch the ones that matter to you, when it suits you, and comment on the moment you mean. Each demo ends with the questions we need you to answer. Please leave your feedback by [day and date]. We’ll reply to every comment and share what changes as a result.
Checklist
Async sprint review checklist
Run through it every sprint until it’s a habit.
Before the sprint ends
- Reviewers chosen for each piece of work, with one person who must answer
- A feedback deadline about two working days after posting
- A short live meeting booked, only if a decision needs one
Recording
- One demo per feature or fix, 3 to 5 minutes each
- Notifications off, other tabs closed, text large enough to read
- The goal in the first 30 seconds
- Unfinished parts named, and your questions asked at the end
Posting
- A title that says what changed
- A description that follows the template, with the questions and the deadline
- Stakeholders told where to watch and by when
While feedback comes in
- A reply to every comment
- A ticket linked for anything that becomes work
- Threads resolved once they’re handled
After the deadline
- A summary shared: what you heard, what changes, what was ticketed
- Open questions taken to sprint planning
Copy it as a task list, ready to paste into your tracker or your notes.
With Circlebak
Run your async sprint review in Circlebak
Circlebak is made for this. Teams upload their demos and stakeholders are emailed. Comments are pinned to the moment and linked to tickets, and reminders go out before the deadline. Reviewers are always free.
Circlebak in 90 seconds
Read the transcript
Your engineering team just spent the whole sprint building something new.
So you book a demo… and suddenly, everyone's too busy to make it.
Plan B? Book the whole department into one three-hour demo.
But nobody sits through three hours for the one feature they care about. So the people you need… don't show up.
And the recording? Good luck finding their part.
So it ships without their feedback. It's not what anyone expected. Now you're paying to rebuild it, and your clients have noticed.
That's where Circlebak comes in.
Skip the giant meeting. Each team records a short video of their work, and hits publish.
Tag the stakeholders who care. They're notified right away, and nudged before the feedback window closes.
They watch whenever it suits them, and comment right on the moment that matters.
Link any comment to its Jira, Linear or GitHub ticket, and follow it all the way to done.
So the gaps get caught before launch, not after. Less rework. No awkward client calls.
And you can start for free. You only pay for the people who upload videos, from $12 a month each. Reviewers? Always free.
Circlebak. Show the work before it ships.
Free for one creator. Reviewers are always free. 14 days of Business with no card.
Questions
Questions about async sprint reviews
How long should an async sprint demo be?
- Three to five minutes for each piece of work: long enough to show the flow from start to finish, and short enough that people watch to the end. If one runs longer, split it into two demos.
How long should stakeholders have to give feedback?
- Two working days suits most teams. Give at least one full working day in every time zone you work across, and close it before sprint planning so the feedback can shape the next sprint.
Who should watch the sprint demos?
- Anyone who will sell, support, design around or decide on the work: product, design, sales, support, customer success and leadership. Choose them for each piece of work, not for the whole sprint, so each person sees what matters to them.
What if stakeholders don’t watch?
- Make it easy to say yes: short demos, one per topic, a clear question for each person, and a date. Mention the person whose answer you need. If someone never watches, ask whether they need to review that work at all.
Is an async sprint review still a Scrum sprint review?
- It can be. The Scrum Guide calls the sprint review a working session where stakeholders inspect the work and the team adapts what comes next. That still happens if stakeholders respond and the plan changes because of what they say. Teams that need to discuss the product goal or the backlog often add a short live meeting for that.
What’s the difference between a sprint review and a retrospective?
- The review is about the product: what was built and what should change. The retrospective is about the team: how you worked together and what to do differently. This guide covers the review.
Put your next demo in front of the people who need to see it
Try every Circlebak feature free for 14 days, then keep the Free plan or pick the one that fits. Reviewers are always free.