Skip to content

Async standup questions: templates for small teams

The classic three standup questions, five variations for agencies, studios and dev shops, and the mistakes that turn an async standup into noise.

·6 min read

A daily standup meeting for a team of six costs 15 minutes each, which is an hour and a half of team time every day, mostly spent listening to updates that don't concern you. Move it to writing and each person spends three minutes, and you can read everyone's in five.

The catch is that async standups live or die on the questions. Ask the wrong ones and you get "working on stuff" from half the team and an essay from the other half. Below are question sets that work, by type of team, and the mistakes that kill them.

The base template

Every good async standup is a variation on three questions:

1. What did you finish since your last update?
2. What are you working on next?
3. Is anything blocking you, or at risk of slipping?

Notice the wording. "Finish" instead of "work on", because finished things are checkable and "worked on" is not. "At risk of slipping" alongside "blocking", because people rarely admit to being blocked until it's too late, but they will admit something might slip.

Five variations for service businesses

For a client-services agency

Client work has a dimension that internal product teams don't: someone outside is waiting.

1. What did you deliver or move forward today, and for which client?
2. What's next, and is any of it due to a client this week?
3. Are you waiting on anything from a client or from someone here?

The third question separates "waiting on the client" from "waiting on us", which are very different problems. The first is a client-management issue for the account lead. The second is yours to fix.

For a dev shop

1. What did you merge, ship or close?
2. What are you picking up next (ticket number)?
3. Anything blocking: reviews, environments, access, unclear specs?

Listing the common blockers prompts people to mention them. Developers will quietly wait two days for a code review rather than ask; naming "reviews" in the question makes it normal to say so.

For a design or creative studio

1. What went out for review or approval today?
2. What are you designing or revising next?
3. Any feedback you're waiting on, or a revision round that's growing?

The last part matters for margin. Creative work goes over budget in the fourth and fifth revision rounds, and the designer is the first person to know it's happening.

For a consultancy

1. What did you produce or decide with the client today?
2. What's the next deliverable and when is it due?
3. Any risk to the timeline or scope that the engagement lead should know?

For a mixed team in several time zones

1. What did you finish (with a link if it's reviewable)?
2. What are you doing next?
3. Who do you need something from before your next day starts?

The third question is the time-zone trick. If your developer in Lahore needs a decision from your account manager in London, saying so in the end-of-day update gives London a full day to answer before Lahore starts again. More on this in running delivery teams across time zones.

Optional questions to rotate in

Use these once a week, not daily. Daily, they become chores.

QuestionWhat it catches
What took longer than you expected this week?Bad estimates before they become a pattern
Is there anything you're doing that feels like a waste of time?Process debt, pointless meetings, duplicate work
What did a teammate help you with?Who's quietly holding things together
On a scale of 1 to 5, how was your workload this week?Early burnout, or idle capacity

The workload question is worth keeping. A run of 5s from one person and 2s from another is a resourcing decision you can make on Monday instead of discovering in a resignation.

Morning plan, evening check-out

Most templates ask all three questions at once. There's a better split for small teams:

  • Morning: what will you work on today? One or two lines.
  • Evening: what got done, what didn't, and why?

The plan creates a small commitment. The check-out compares it with reality. When someone plans three things and finishes one, the "why" is useful information: the client called, a bug ate the afternoon, the task was bigger than it looked. Over a few weeks the pattern tells you more than any productivity metric.

This is the shape Check-ins in Suprwork uses: people type or say their plan in the morning, it becomes their list for the day, and they check out the same way at the end. Spoken check-ins are transcribed and translated to English, which helps on teams where not everyone writes English comfortably.

Where to run it

You don't need a tool to start. A dedicated chat channel and a pinned template will carry a team of up to about eight. Rules for the channel:

  1. Updates only. No replies in the main channel; discuss in a thread.
  2. One message per person per update, using the template.
  3. Posted by a set time in each person's own day.

Past about eight people, the channel turns into a wall you won't read. At that point you want something that collects the answers per person and gives you one summary.

Mistakes that kill async standups

Asking too many questions. Five daily questions is a form, and people resent forms. Three, plus one rotating weekly question at most.

Nobody reads them. If the founder never responds to a standup, the team concludes it's for show. Reply to one or two a day with something specific.

Using it to judge, not to unblock. The moment someone gets a sharp message because their "done" list looked short, every future update gets padded. Keep performance conversations in 1:1s.

Duplicating the board. If your tickets already show status, don't make people retype ticket titles. Ask about what the board can't show: blockers, risks and decisions needed.

Making it a meeting anyway. Some teams go async and then hold a call to "discuss the standups". Discuss blockers in threads with only the people involved. Keep one weekly call for decisions.

A filled-in example

Here's what a good week looks like for one person on a web agency team:

Mon
Done: Homepage build finished, sent to Priya for QA
Next: Product page templates for Northfield
Blocked: Need product photos from Northfield (asked Thursday)

Tue
Done: Product page template 1 of 3
Next: Templates 2 and 3
Blocked: Still no photos. Using placeholders; Northfield launch date at risk if not by Thu

Wed
Done: Templates 2 and 3, QA fixes from Priya
Next: Checkout styling
Blocked: Nothing

By Tuesday, the account lead knows the client is the blocker and has two days to sort it before it affects the launch. Nobody had to ask.

This week

Pick the variation that fits your team, post it in a channel with the filled-in example above, and run it for two weeks without changing anything. Then ask the team one question: which line do you find hardest to answer? That's the line to reword.

Common questions

What are the three standup questions?
What did you do since the last update, what will you do next, and is anything blocking you. Most async templates are a variation of these three.
How long should an async standup answer be?
Two to five lines. If people write paragraphs, the questions are too open or the standup is being used as a report.
Should an async standup be in the morning or the evening?
Morning for a plan, evening for what actually happened. Many small teams do both in two short parts: a plan at the start of the day and a check-out at the end.
Do async standups replace meetings?
They replace the daily status meeting. Keep a short weekly call for decisions and anything that needs discussion.

Keep reading