非同步每日站會：何時有效，何時不適用

An async daily standup sounds like the perfect fix for distributed teams at first: everyone posts a short note in a thread in the morning, and nobody has to break their focus for a call at 9:15. I keep coming back to this topic because hardly any ritual triggers as many opinions as the daily. Some people love those 15 minutes as a social anchor. Others experience them as a daily accountability report that interrupts exactly when their head is finally clear.

I am neither in the “kill the daily” camp nor in the “the daily is sacred” camp. So in this article we take a sober look at what the Scrum Guide actually asks for, what research has found about stand-ups, and how to introduce an async daily standup so that it helps the team instead of just producing text. You get a template, a step-by-step plan for a four-week experiment, and an honest list of situations in which I would stick with the live meeting.

In short

An async daily standup is a good replacement for the status part of a stand-up, but not for adjusting the plan together. A mix of short written updates and a few fixed live meetings works best. The biggest pitfall: updates nobody reads and blockers that get lost in the thread.

What you will learn in this article

What the Scrum Guide really requires for the daily, and what it does not
Which stand-up problems a study of 15 teams found
When an async daily standup fits and when you should stay live
A template and a process for a four-week team experiment

What is an async daily standup?

In an async daily standup, the team does not meet at a fixed time. Instead, each person writes a short update in an agreed time window in a fixed place, for example a thread in the team chat or a comment on the board. Everyone else reads the updates when it fits their day and responds if needed.

“Asynchronous” simply means that sender and receiver do not have to be present at the same time. That is the big advantage for teams spread across several time zones or with very different working hours. At the same time, it is also the biggest weakness, because follow-up questions take longer and misunderstandings surface later.

What the Scrum Guide says about the daily

If you work with Scrum, you quickly end up asking whether an async daily standup is even “allowed”. The 2020 Scrum Guide describes the Daily Scrum as a 15-minute event for the Developers held daily at a fixed time and location. It exists so the team can check how it is doing against the Sprint Goal and change the Sprint Backlog where needed.

More important, in my view, is the part that people often skip: the Developers can choose whatever structure and techniques they like, as long as the daily focuses on the Sprint Goal and ends with an actionable plan for the next working day. The guide also makes clear that the daily is not the only moment when the team is allowed to adjust its plan.

My reading: a purely written update only partly fulfils the idea of a shared event. Inspecting and adjusting is a conversation, not a report. An async daily standup can therefore take over the information part. For replanning together, you still need a place where people talk to each other. Whether that has to happen every day is a different question.

What research says about stand-ups

The debate about the daily is often driven by gut feeling. That is why it pays to look at a study I find very helpful for this topic. For their article “Daily Stand-Up Meetings: Start Breaking the Rules”, Viktoria Stray, Nils Brede Moe and Dag Sjøberg observed 102 stand-ups and interviewed 60 members of 15 teams in five countries.

The most common problems

Many readers will recognise the findings. Often the meeting turned into a status report for the manager or the Scrum Master. A lot of the information was not relevant to the others at all, because roles, tasks and experience in the team differed widely. In addition, the fixed slot chopped up the working day, which bothered developers in particular during focused work.

One detail struck me as especially revealing: when participants spoke to the facilitator, the meeting became a report. When they spoke to each other, a real discussion emerged. In the study, poorly experienced stand-ups also went hand in hand with lower job satisfaction and less trust within the team.

Four recommendations that fit the topic

The authors propose four changes. First, drop the question “What did I do yesterday?” and share status via a board or a chatbot instead. Second, rotate the facilitation. Third, schedule the meeting right before lunch so that it does not cut through a focus block. Fourth, adjust the frequency, because five meetings a week are not a must for every team.

Taken together, the first and the fourth recommendation are essentially the blueprint for a hybrid async daily standup. Status goes in writing, problem solving happens live, and only as often as the team really needs it.

When an async daily standup works

An async daily standup is not a cure-all, but in some situations it clearly plays to its strengths. For example, when your team is spread across several time zones and any fixed slot falls at the edge of somebody’s working day. Teams with many part-time members or flexible hours also benefit, because nobody has to rearrange their day for 15 minutes.

It also works well when the team is well established, the Sprint Goal is clear and the board reliably shows the current state anyway. Then the updates are short and mostly about dependencies and blockers. Teams that do a lot of deep work also gain uninterrupted focus time.

When you should stay live

There are equally clear signals against an async daily standup. If the team has just been put together, the trust needed to raise problems openly in writing is missing. In hot phases, for instance shortly before a release or during an incident, a quick call is almost always faster than a thread. The same applies when the Sprint Goal is shaky or many tasks depend on each other.

I would also pay attention to tension in the team. Written communication loses tone and facial expression, and a curt “still on it” can land very differently depending on the mood. I have described how to phrase feedback in chat without hurting anyone in Written Feedback in Remote Teams: Chat or Call?. Incidentally, the GitLab handbook on asynchronous work recommends deliberately switching to a call after several rounds of back and forth in exactly these cases.

Introducing an async daily standup step by step

I would never impose an async daily standup from above. It is a team ritual, so the team decides, based on an experiment with a clear end. The following process is designed so that you can run it within two sprints or four weeks.

Prerequisites

You need a board that reliably shows the state of the work, a team chat with threads, and a team that itself sees room for improvement in the current daily. Without that dissatisfaction, there is no reason for the experiment. A clearly worded Sprint Goal that the updates can refer to also helps.

The process in seven steps

Name the problem together. Talk in the retro about what bothers people about the current daily. Is it the time, the length, the status-report feel or the time zones? The goal of the experiment should address exactly this problem.
Agree on an experiment with an end date. Decide to test the async daily standup for four weeks and to make a conscious decision afterwards. That way nobody feels steamrolled, and sceptics are more willing to join in.
Define channel and time window. One fixed thread per day, for example started automatically by a bot at 8 a.m. Everyone posts their update in this thread by 10:30 a.m., not in direct messages.
Introduce a template. Use a short, fixed structure (see below). Deliberately leave out the question about yesterday, because the board shows that.
Keep live anchors. Schedule 15 minutes live twice a week, for example on Tuesdays and Thursdays. These meetings are only about the Sprint Goal, blockers and replanning.
Rotate a daily buddy. One person per week reads all updates by 11 a.m., summarises open blockers and sets up a short call with the people involved if needed. The role changes every week.
Evaluate and decide. After four weeks, look at the results together in the retro and decide: continue, adjust, or go back to the live daily.

Expected outcome after the experiment: you have made a conscious decision based on your own experience rather than on a blog post. “We are keeping the live daily, but moving it to just before lunch” is a good outcome too.

The update template

The template should be short enough that an update takes two minutes to write. I would start with these four fields and adjust them after the first week:

Today: What am I working on, in relation to the Sprint Goal?
Blockers: What is holding me up? Whom do I need for it?
Note: What should the others know? (optional)
Mood: 1–5 (optional, no explanation needed)

To give you a feel for the length, here is an example from a made-up team building an app for a bike rental shop:

Today: Finish testing booking cancellation (Sprint Goal: cancel in the app)
Blockers: Need a quick answer from Jana on which fees apply to cancellations after 6 p.m.
Note: The test environment is unavailable between 1 and 2 p.m. due to an update
Mood: 4

The mood field is deliberately optional. It does not replace a conversation, but it gives the daily buddy a hint about where a short call might help. Important: a low number is an invitation to talk, not a reason to ask questions in the public thread.

The weekly rhythm at a glance

The following diagram shows how written updates and live meetings are spread across the week. Blockers do not wait for the next meeting. They go into a short call the same morning.

Hybrid weekly rhythm: written every day, live twice a week, blockers go straight to a call.

Tips on tools

You do not need a special tool. Most team chats can trigger recurring messages or simple workflows that start a thread with the template every morning. There are also bots that ask the questions one by one and collect the answers. To get started, a recurring reminder is perfectly sufficient. If the experiment works out, you can still automate later.

Common mistakes with an async daily standup

The most common mistake is that nobody reads the updates. Everyone dutifully writes their text, but blockers stay untouched, and after two weeks the whole thing feels like bureaucracy. The rotating buddy role from step 6 exists precisely for this.

A second classic is the status report upwards. If the manager comments on every update or asks why something is taking longer, the team ritual turns into a control instrument. As a leader, I would therefore deliberately hold back in the thread and mainly respond to blockers where I can really help.

Third, updates tend to grow into small novels. Anyone who writes five paragraphs will not be read. A guideline of three to five lines helps, and details belong in the ticket. Fourth, a replacement for the social part is often missing. For many people, the daily was the only moment of the day when they saw the others. If it disappears, you need another place for that, such as a relaxed coffee round. I describe what such rituals can look like in distributed teams in Leading remote teams: rituals that actually work.

The fifth mistake is more subtle: the team abolishes the daily without anchoring the inspection of the Sprint Goal somewhere else. Then you only notice in the review that the goal had been out of reach for a week already.

My take

For me, the daily is above all a tool for staying on course together. If a written update delivers the status part faster and with fewer interruptions, that is a win. But I also see that the status part is often the least important one. The real value of the daily lies in the two minutes when someone says: “Wait, that is connected to my task.” Moments like that happen much more easily in conversation than in a thread.

That is why my favourite is a hybrid approach: written updates on most days, plus two or three short live meetings per week that focus only on the Sprint Goal and blockers. How often you meet live is something the team should decide for itself and review regularly. What I would not recommend is an async daily standup as a cost-cutting measure or as a reaction to a bad atmosphere. If people do not like coming to the daily, it is rarely because of the time of day. In that case, an honest conversation about why is the better first step.

FAQ

Is an async daily standup compatible with Scrum?

Partly. The Scrum Guide describes the Daily Scrum as a 15-minute event at a fixed time and location, but leaves structure and techniques open. A written update can deliver the information part. Inspecting the Sprint Goal together and replanning should still have a fixed place, ideally in short live meetings.

How long should an async standup update be?

Three to five lines are almost always enough. If an update gets longer, the details belong in the ticket or in a separate thread. As a rule of thumb, it should take two minutes to write and 20 seconds to read.

Which tools work for an async standup?

To start, the team chat with a daily thread and a recurring reminder is enough. Many chat tools can trigger workflows that post the template automatically. Dedicated standup bots only pay off once the team wants to use the format long term.

How often should a team still meet live with an async daily standup?

That depends on the team. Many teams do well with two to three short live meetings per week. In hot phases, such as before a release, it can make sense to temporarily go back to talking live every day.

Your next step

Bring the topic into your next retro with a single question: “What would we miss if the daily took place in writing from tomorrow?” The answers will quickly show you whether an experiment makes sense and which live anchors you should definitely keep. And I am curious: have you ever tried an async daily standup, and what made you stick with it or go back? Let me know in the comments.

Sources

This post was created with AI assistance.

👉 Next step: More for team leads: my cheat sheets put the essentials on one printable page.

Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en