An asynchronous retrospective lets a team reflect on its work, prioritise problems and agree improvements at different times, without everyone joining one meeting. Give each stage a clear deadline, appoint a facilitator and finish with an agreed action, an owner and a review date.
The useful part is the flexibility. People can contribute during their working day rather than joining another awkwardly timed call. The difficult part is reaching a decision when nobody is in the same room. A board left open indefinitely will not solve that for you.
This guide includes a practical workflow, a 48-hour example for teams with overlapping working hours, and messages you can copy. For a team spread across distant time zones, give the stages more time.
Choose async or hybrid before choosing a template
Use a fully async retrospective when the topic is bounded, the team can explain observations in writing and the decisions can wait for everyone to contribute. A routine review of handoffs, review delays or meeting habits is a reasonable place to start.
Choose async preparation followed by a short live discussion when observations are disputed, the team needs to explore a difficult trade-off, or written replies keep missing one another's point. GitLab's communication guidance uses repeated back-and-forth as a signal to consider a call. Keep the eventual decision on the board so absent colleagues can understand it.
Serious interpersonal conflict, confidential personnel matters and urgent operational incidents need the appropriate facilitated or private process. An anonymous board does not make every topic safe to discuss with every participant.
For a live format, use the remote retrospective facilitation guide.
Set up a board with a clear finish
Start with three columns: What helped, What got in the way, and What could we try. Keep the scope to one sprint, one project milestone or another shared period. Nextretro participants can join from a shared board link without creating an account.
Before inviting the team, write down:
- The period and question being reviewed.
- The facilitator and where to ask questions.
- Who can access the board and whether author names are hidden.
- The collection, grouping, voting and discussion deadlines, with a time zone.
- How the team will choose an action and confirm its owner.
- When you will review whether the change helped.
Explain anonymity accurately. Hiding author names does not prevent colleagues from recognising an event or writing style. Ask people to describe the work and its consequences without adding unnecessary personal or customer information.
Nextretro's async deadline controls let a facilitator set Closes at on a step, with the board advancing when that time passes. This is available on every plan. Check the schedule before enabling automatic transitions: the deadline controls the workflow, but it cannot tell whether an important perspective is missing.
A 48-hour asynchronous retrospective agenda
The following example runs from Monday at 13:00 UTC to Wednesday at 13:00 UTC. It suits a team whose normal working hours include the short Tuesday windows. These are suggested timings, not a requirement or a claim that every team can finish in two days.
| Stage | Example window in UTC | Team contribution | Facilitator output |
|---|---|---|---|
| Collect | Monday 13:00 to Tuesday 13:00 | Add observations and answer factual questions | A board with specific examples from the period |
| Group | Tuesday 13:00 to 14:00 | Available participants flag mistaken groupings | Related cards organised under clear themes |
| Vote | Tuesday 14:00 to 16:00 | Read the themes and vote on what deserves attention | A shortlist for discussion |
| Discuss and agree | Tuesday 16:00 to Wednesday 13:00 | Suggest a small experiment, raise concerns and confirm ownership | An agreed action, review date and written summary |
Grouping is mainly facilitator work in this example. Explain the proposed groups clearly enough that people can challenge them during discussion. If a correction would materially change the vote, revisit the priority rather than treating the count as final.
For a widely distributed team, use a longer version: allow a full 24-hour collection window, facilitator grouping during an agreed working period, a full 24-hour voting window, and another full 24-hour discussion window. Allow more time around weekends, holidays or part-time schedules. The important check is whether each participant has a normal working opportunity in every stage requiring their input.
Do not ask someone to stay online just to satisfy a 48-hour target. Publish actual dates as well as times, and ask participants to flag an inaccessible window before you start.
Create a free retrospective board in Nextretro and share the schedule alongside its link.
Collect observations that others can understand
Ask for one observation per card. A useful card explains what happened, when it happened and what effect it had. It should be understandable without a live explanation from its author.
Try these prompts:
- What helped us complete a piece of work, and should happen again?
- Where did work wait, repeat or arrive without enough context?
- What small change could make the next cycle easier to complete?
For example, “Reviews were slow” leaves several questions unanswered. A more useful card is: “Four pull requests waited until the final sprint day for a first review, leaving little time to respond.” This is a fictional example, not a Nextretro customer result.
If the author does not know the cause, leave it open. The delay might reflect unclear reviewer ownership, large changes, competing priorities or missing context. Writing “people ignored reviews” turns an observation into an accusation before the team has investigated it.
The facilitator should ask short factual questions and correct misunderstandings without arguing a preferred explanation. Keep relevant evidence linked in its approved location rather than copying confidential material into the board.
Group without losing disagreement
Give related cards a descriptive title, such as “First reviews arrive late”. Avoid broad categories like “Communication” that can hide several different problems.
Preserve the distinction between a repeated observation and a competing explanation. A card about unclear ownership and a card about large pull requests may belong to the same theme, but they do not establish the same cause.
Leave room for a minority observation. One person may have encountered a serious issue that nobody else saw. Ask whether it needs a separate response, even if it will not win a vote.
Before moving on, make the instruction explicit: “Check whether your card still means what you intended. Flag anything that has been merged into the wrong theme.”
Vote on attention and agree the action separately
Set the same vote allowance for everyone and explain the question: Which problem would be most useful for us to understand and improve next? Three votes per person is a simple starting point, not a rule.
A vote helps choose the discussion order. It does not prove a cause, approve a solution or volunteer someone to do the work. Security, safety and other required controls should not depend on popularity.
For each shortlisted theme, ask:
- What do we know, and what are we assuming?
- What is a small change within the team's control?
- Who can coordinate it, and do they agree?
- What evidence will we review, and when?
Keep the first trial small. For the fictional review-delay example, the team might agree:
For the next sprint, Priya will coordinate a daily review triage check during the team's shared working window. Each waiting pull request will have a named next reviewer. At the next retrospective, we will review first-review waiting times and ask whether the check caused extra interruptions.
Priya must accept the role and have time to do it. Until then, label the action proposed. Silence or an expired deadline is not agreement.
If the discussion stalls, arrange a focused call with the people needed to resolve it, then return the reasoning and proposal to the board. Give affected colleagues a chance to respond before presenting it as a team commitment.
The retrospective action-items guide has more examples, and the action item builder helps turn a vague intention into a reviewable experiment.
Copyable invitation and reminder
These are messages for the facilitator to send through the team's usual channel. Replace the bracketed fields and check every deadline before sending.
Invitation
Let's review [sprint or project period] asynchronously on [board link]. Our question is: [specific question].
Add observations by [date, time and time zone]. I will group them by [deadline]. Please read and vote by [deadline], then discuss the leading themes and proposed actions by [deadline].
Plan for three short visits: add cards, read and vote, then discuss the proposed action. Allow around 10 minutes per visit as a starting point; discussion may need longer. You do not need to stay online. Tell me if a window falls outside your working hours.
[Explain who has access and whether author names are hidden.] Keep cards specific to the work. Put questions in [location]. We will close with an agreed experiment, an owner and a review date.
Reminder
Our retro is now at [stage] and closes at [date, time and time zone]. The next step is [specific contribution] on [board link]. If the deadline or access is a problem, let me know so we can address it before closing.
Send reminders intentionally. Do not create a string of urgent pings during other people's evenings. Automatic step advancement and reminder messages are different things.
Close with a decision people can find
Before closing, check that the selected action has an accepted owner, a realistic scope and a review date. Summarise unresolved questions as unresolved; a tidy board is not a reason to invent agreement.
A useful closing message is:
We chose [experiment] because [observation]. [Owner] has agreed to coordinate it from [start date]. We will review [evidence] on [review date]. [Open issue] remains unresolved and will be handled through [next step]. The full context is on [board link].
On the free path, export the retro or copy the agreed action into the team's existing action register. At the next retro, check both whether the action happened and whether it helped. A completed triage check is an activity; shorter waits without excessive interruptions would be evidence worth examining.
Nextretro Plus adds a follow-through loop that carries open actions into the next retro for review. It also includes full history and team workspaces. Current pricing is €9.99 per facilitator per month or €99 per year, with participants free. You do not need Plus to try the async workflow: Free includes boards, participants, voting, comments, anonymous mode, step deadlines and PDF or Markdown export.
Start with one retrospective and one change the team can review. Decide whether the format helped after you have seen the follow-through.
Common questions
Can the entire retrospective be asynchronous
Yes, if the team can clarify observations and explicitly agree a next step in writing. Keep a hybrid option for contested or sensitive topics. Finishing without a call is less important than reaching a useful, understood decision.
How long should an async retrospective stay open
Long enough for every participant to contribute during normal working hours at each relevant stage. The 48-hour example works only when the shorter windows are accessible. For distant time zones, use full-day voting and discussion windows and a longer overall schedule.
What if someone misses a deadline
Check why and whether their missing perspective could change the decision. Fix access problems, allow more time where necessary, or record the limitation. Do not mark an absent person's action as accepted. If late evidence changes a theme materially, reconsider the proposed action.
Does this replace the Scrum Sprint Retrospective
This is a general team retrospective workflow, not the Scrum Guide's prescribed event timebox. The Scrum Guide says the Sprint Retrospective concludes the Sprint and is timeboxed to a maximum of three hours for a one-month Sprint. Scrum teams can use async collection to prepare for their event; do not describe a 48-hour contribution window as the Scrum timebox.