Sprint planning was designed for a co-located team in a conference room with a whiteboard. Distributed teams trying to recreate that experience over Zoom usually end up with a two-hour meeting that costs everyone the same day. The async version is structurally different — it splits the work the meeting was doing into three stages: a written proposal, an async review window, and a short synchronous commit. The total elapsed time is longer, but the total engineering time consumed is much shorter, and the resulting plan is usually better-considered.
The template below is the structure of those three stages, with the artifacts each one produces. It is designed to fit in a single working week and to leave the team with a sprint plan that the team genuinely committed to, not a sprint plan that the loudest person in the meeting committed to on everyone's behalf.
When to use it
- Your team spans more than three time zones and the planning meeting has become miserable.
- Sprint planning regularly runs over its allotted time.
- Engineers commit to work in the meeting and then quietly cut it during the sprint.
- You suspect the sprint plan is being made by two or three people while the rest of the team is silent.
The template structure
This is the structure of the template. Copy it into a Notion page, a Linear doc, or a markdown file in your repo — it works in any of them.
ASYNC SPRINT PLANNING — Sprint [N]
Dates: [start] – [end]
Facilitator: [name] Owner of plan: [name]
STAGE 1 — PROPOSAL (Day 1, written by facilitator)
Posted by: end of [Monday]
Sprint goal: one sentence
Theme(s): 1–3 themes
Proposed work, by area:
[area]:
[ticket] — [estimate] — owner: [name or open]
[ticket] — [estimate] — owner: [name or open]
[area]:
[ticket] — [estimate] — owner: [name or open]
Carry-over from last sprint:
[ticket] — [why it carried] — owner: [name]
Excluded (but considered):
[ticket] — [why not this sprint]
STAGE 2 — ASYNC REVIEW (Day 2–3)
Each team member responds in the doc:
[ ] I have read the proposal
[ ] I have at least one item I plan to own
[ ] My objections (if any):
[ ] My estimates I disagree with (if any):
[ ] Items I think should be cut:
[ ] Items missing that I would add:
Deadline for review: end of [Wednesday]
Silent = consent only if the engineer explicitly checks the box.
STAGE 3 — COMMIT (Day 4, 30-min sync)
Quick walk through unresolved threads.
Adjustments, if any, made live.
Final scope written down.
Owners locked in by name.
Sprint goal confirmed.
DURING THE SPRINT
Mid-sprint check: written, end of [day N of sprint].
- On track / at risk / behind, by ticket
- Carry-over risk identified early
- One thing the team should know about
END OF SPRINT
Retro happens as usual (different template).
Carry-over moves to next sprint's Stage 1 doc, with reasons.
ROLES
Facilitator: writes Stage 1, runs Stage 3.
Owner of plan: keeps the doc up to date during the sprint.
Engineers: respond to Stage 2 explicitly.
Governance, not a status channel
StandIn is async governance infrastructure. Engineers declare working state before they go offline. Representatives answer from the record, cite the source, and refuse when the answer is not there.
Request access →How to use it well
- Stage 2 silence is not consent. The checkbox is the consent. An engineer who did not respond to Stage 2 is not committed to the sprint, no matter what the facilitator wrote. This rule is the entire point of the format.
- Keep Stage 3 to thirty minutes. If the synchronous commit runs over, Stage 2 didn't surface enough of the disagreement. Extend Stage 2 next sprint, not Stage 3.
- The mid-sprint check is in writing. A mid-sprint sync meeting is the failure mode that this format was designed to prevent. Write it down; the team reads it on their own time.
- Carry-over goes in next sprint's Stage 1 with reasons. "Why this carried" is the data that improves estimation. Without it, the team keeps over-committing in the same ways.
- The owner of the plan is not the manager. The plan owner keeps the doc current during the sprint. It is a rotating role; everyone takes it once. Engineers who have owned a plan estimate better.
What to skip
Skip story points if your team has never converged on what they mean. T-shirt sizes (S/M/L) cost less in calibration time and give the same predictive value at the team level. The goal of estimation is a forecast, not a science experiment.
Skip planning poker at the async stage. The whole format exists to remove synchronous estimation games. If estimates are disputed, the disputes go in the Stage 2 doc and get resolved at Stage 3 — by the engineers who will do the work, briefly, in writing first.
Frequently asked questions
Is this template free?
Yes. The flow above is the template. Use a Notion page per sprint and link it from your team's operating manual.
Can I edit it?
Yes. Common edits: dropping the Themes line if your sprints are pure maintenance, adding a Risk section if your team works on time-critical migrations.
Do I need to give my email?
Not for the structure. The download is a Notion version; the email is just for the newsletter.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.