Async standup templates that beat yesterday, today, blockers

The three classic questions work in a room because people can ask follow-ups. Written down and posted to a channel, they tend to produce lists nobody reads. These seven formats hold up in writing, each with a filled-in example.

By the VeoRec team · Oct 3, 2026 · 12 min read

An async standup template is a short, fixed set of prompts each person answers in writing (or in a short video) at a set time, instead of meeting for a daily standup. The classic version is three questions: what did you do yesterday, what will you do today, and is anything blocking you? It is a fine starting point. It is also why so many async standups turn into a wall of task lists that nobody reads past Tuesday.

This post explains why, then gives seven templates you can copy, with filled-in examples, guidance on timing across time zones, when a video standup is worth it, and how to stop the routine going stale.

Why the classic three questions fall flat in writing

In a room, "yesterday I worked on the import feature" is the start of a conversation. Someone asks "is the CSV thing sorted?", and the useful information comes out. Written down, the follow-up never happens. You get a list of activities, and the reader has to guess what matters.

It is worth knowing that the three questions were never mandatory. The current Scrum Guide describes the Daily Scrum as a 15 minute event to inspect progress toward the Sprint Goal and adapt the plan, and says developers can pick whatever structure and techniques they want, as long as the result is focused on that goal and produces a plan for the next day. It also notes the Daily Scrum is not the only time a team is allowed to adjust its plan.

There is a second problem. Written answers to "what did you do yesterday?" drift towards proving you were busy. People list meetings attended and tickets touched, because that looks like effort. A reader learns who was active, not whether the team is closer to its goal. Good prompts make it easy to say "I spent the day stuck on one problem, here is where it is", which is often the most useful update anyone posts that week.

That gives you permission to design prompts that work in writing. The good ones share three traits:

• They point at the goal. "Progress toward the sprint goal" forces a judgement. "What I did" invites a log.
• They make needs explicit. A blocker without a named person is a complaint, not a request.
• They are short. Three to five lines. Anything bigger is its own post or document, linked from the standup.

Copy an async standup template that fits your team

Pick one format and use it for at least two weeks before judging it. Swapping formats every few days makes everyone think about the template instead of the work.

If you are unsure, start with goal-first. It is the closest to what the Scrum Guide asks of a Daily Scrum, it works for non-engineering teams too, and it is the hardest to fill in on autopilot, because "on track because..." makes you think for a moment.

See the difference in real examples

Take one developer's Tuesday, written up twice: once as a typical update, once as a useful one. Both took about the same time to write.

The first version hides a blocker ("waiting on some stuff") and gives a reviewer no reason to act. The second puts the blocker on line one with a name, links the work, and connects it to the goal. The goal-first template works just as well outside engineering:

• Designer: "Sprint goal: new onboarding live Friday. Progress: at risk, the empty states are not designed yet. Today: empty states for the three dashboard cards, in the file by 15:00. Need: 10 minutes from @Ana to confirm copy for the empty project card."
• Support lead: "Goal: cut first-reply time under 4 hours. Progress: on track, 3.2 hours yesterday. Today: macro for the password reset spike. Need: nothing."
• Product manager: "Goal: decide Q4 pricing test. Progress: off track, finance review moved to Thursday. Today: draft the test plan so we lose no time after. Need: @Leo, can you share last quarter's conversion by plan by Wednesday?"

And one using the end-of-day template, from a developer in Berlin on a team that also works from Toronto: "Today I finished: retry logic for failed webhooks, merged (PR #519). Tomorrow I start with: the alerting dashboard. Open question for the team (answer by my morning): @Maya, should failed webhooks retry 3 or 5 times before we alert? I went with 5, easy to change." Maya answers in her afternoon, and the work never waits.

Decide when people post and when they read

An async standup only works if updates arrive before people need them. On a team in one time zone, start-of-day posting is simple: everyone posts by 10:00 and reads the others before starting deep work. Across time zones, the answer changes.

Work it through for a team split across San Francisco, London and Bengaluru in summer, everyone posting at the end of their own day. Bengaluru posts at 18:00, which is 13:30 in London and 05:30 in San Francisco. London posts at 17:30, which is 22:00 in Bengaluru and 09:30 in San Francisco. San Francisco posts at 17:00, which is 01:00 in London and 05:30 the next morning in Bengaluru. Each office starts its day with fresh updates from the other two, and London, in the middle, can still answer a Bengaluru blocker the same afternoon.

The weak spot is San Francisco to Bengaluru: a question posted at 17:00 in California is read at the start of the Indian day, but the reply lands after California has gone home. If those two groups depend on each other often, agree a short overlap (early morning in California is evening in India) for the rare blocker that cannot wait a full day.

Reading matters as much as posting. Make it a habit: when you post your update, read everyone else's and reply to any blocker you can help with. That one rule keeps blockers from sitting overnight. 37signals runs a version of this with an automatic daily "What did you work on today?" check-in, described in their guide to how they communicate; the answers sit in one place where anyone can read them.

Use a short video only when showing is faster

Most daily standups should be text. Text is faster to read than video is to watch, and it is easy to scan for the one line that concerns you. But there are days when a 60 to 90 second recording says more: the new animation that is hard to describe, a strange bug you hit on staging, a design change that is easier to see than to explain.

If you do record, keep the blocker line in text next to the link. Nobody should have to watch a video to find out you need their help. Keep the recording to the point: headline, show the thing, what is next. If it runs past two minutes it is not a standup any more; it is a walkthrough, and it deserves its own post.

With VeoRec you can record a tab or your whole screen from Chrome, with your voice and an optional camera bubble, and the link is on your clipboard the moment you stop, ready to paste under your text update. The automatic transcript means teammates can read it instead of watching. More on the format on the async standup updates page.

Some teams do a video standup once a week, on Mondays, and text the rest of the week. It is a good compromise: people see each other's faces and work regularly, without the daily cost of recording. On VeoRec, teammates can reply with a timestamped comment on the exact moment they have a question about, which keeps the follow-up attached to the thing it refers to.

Choose where the standup lives

You do not need a special tool to run an async standup. What you need is a place that meets four criteria:

1. One thread or page per day. Updates for the same day sit together, so people read them as a set.
2. Mentions notify. When you name someone in a blocker, they get a notification.
3. Searchable history. You will want to look back at what happened in week 3 when the retro comes round.
4. A reminder. A scheduled message or bot that prompts people at the posting time. Without one, updates drift later each week.

A daily thread in your team chat with a scheduled reminder covers all four. Dedicated standup bots add reports and streaks; they are worth it for larger teams, not essential for small ones. Whatever you pick, avoid the setup where updates go into a private form only the manager reads. Standups are for the team, not for reporting upwards. For a wider look at tools by job, see the async team toolkit.

Handle blockers so async does not slow the team down

The fear with async standups is that blockers sit unnoticed for a day. That happens when blockers are vague, unaddressed or buried. These rules prevent it:

1. Blockers go first Line one of the update, every time. If there is no blocker, say "Blocked: no", so a missing line is never ambiguous.
2. Name one person Mention the specific person who can unblock you, not the channel. "Can someone help?" is addressed to nobody.
3. Say what you need and by when "Need the sandbox key by 14:00 to finish today" tells the reader how urgent it is without a follow-up.
4. The lead checks blockers daily Whoever runs the team scans updates for blockers each day and makes sure every one has a reply.
5. Two days stuck means a call If a blocker survives two updates, book 15 minutes with the people involved. Async is the default, not a rule against talking.

If you lead the team, read the updates for patterns as well as for blockers. A few signals are worth acting on:

• The same task appears under "today" three days running. Something is harder than expected; ask, privately, whether help would be useful.
• Two people are waiting on each other. Connect them directly and agree who goes first.
• Someone's updates get shorter and vaguer. That can be a workload or motivation issue, and a one-to-one is a better place for it than the thread.
• Nobody mentions the goal. Either the goal is unclear or it has changed; restate it in the thread.

Decide whether to keep any live standup

Going fully async is not the only option, and it is not always the best one. Many teams land on a hybrid: written updates every day, plus a short live check-in once or twice a week. The live session then has a different job. It is not for status, because everyone has read the updates. It is for the two or three things the updates raised, and for seeing each other.

Keep a live standup, at least for a while, when:

• The team is new. People who have not worked together yet need the faces and the small talk before written updates feel natural.
• Something is on fire. During an incident or the last week before a launch, a daily 15 minute call coordinates faster than any thread.
• Someone new is onboarding. Hearing how the team talks about its work teaches a new joiner more than reading updates does.
• The written updates keep missing things. If problems repeatedly surface late, the format is not working yet; add a weekly live slot while you fix it.

Drop the live part again when the reason goes away. The common mistake is keeping a crisis-era daily call for months after the crisis, at which point it is a status meeting with extra steps.

Set it up in twenty minutes

The setup is small. What makes it stick is that everyone hears the rules once, at the same time, and the lead follows them visibly in the first week.

1. Pick the template and the posting time Choose one format from above and one posting rule (a fixed morning time, or end of your own day).
2. Create the home A channel or a recurring daily thread. Set a scheduled reminder at the posting time that links the template.
3. Write the three rules at the top Blockers first with a name. Read the others when you post yours. Real blockers do not wait for the standup.
4. Post the first update yourself Make it a good example: outcome-focused, linked, with a clear blocker line (even if it says "no").
5. Book the review Put a 15 minute review in the calendar two weeks out, or add it to the next retro agenda, so the format gets judged on evidence.

Keep the routine from going stale

Every standup format decays. After a few weeks, updates get shorter and vaguer, people copy yesterday's text, and reading them feels like a chore. Some ways to keep them useful:

• Change one prompt each sprint. Swap "today I will" for "the riskiest thing I am doing this week" for two weeks. A new prompt makes people think again.
• Allow "no change" days. "Same as yesterday, still on the parser, no blockers" is honest and fine. Forcing people to fill lines produces noise.
• Look at the standups in the retro. Did they catch problems early? Were blockers answered the same day? If not, change the template.
• Skip it when nothing is moving. During a team offsite or a holiday week, pause the routine instead of collecting empty updates.
• Keep one human prompt. A weekly optional line such as "one thing outside work this week" gives remote teams a bit of the chat a standup in a room used to provide.

Use this quick check every few weeks. Tick what is true for your team right now.

What to do next

Pick one template, post it in your team channel with the posting time and the "blockers first, with a name" rule, and set a reminder. Run it for two weeks, then look at it in your retro. If your team also has a weekly status meeting, replacing it with short video updates is the natural next step, and the async communication guide covers the reply-time norms that make all of this hold together.