Write an Async Standup Update That Helps Someone Act
Use a result, a next step and a specific request, with uncertainty left intact. This suggested format is for a team that has agreed to async updates, not a replacement for the formal Daily Scrum.
Miles Crawford
An async standup is a short written or recorded check-in that teammates review at different times. Its job is to make the next step visible, not to prove you were busy. A useful update says what changed, what comes next and whether anyone needs to act.
This is a suggested format for a team that has agreed to use async updates. It is not a replacement for the Daily Scrum required by Scrum. Scrum.org describes that as a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt their plan, not a status report to a manager.
Use four lines, not a diary
- Changed: the result since the previous update, with a link to the work when useful.
- Next: the next meaningful step, rather than every task on your list.
- Need: the specific input or decision, and who you are asking, if anyone.
- Watch: uncertainty or a dependency that could change the plan.
You do not need a blocker in every update. Say "No help needed right now" when that is true. Do not write "Done" if implementation is finished but review or release is still pending.
Decide where the update belongs
| Situation | Put in the routine update | Handle separately |
|---|---|---|
| Progress without a request | Result, next step and work link | Keep technical detail in the linked issue or document |
| Blocked dependency | What cannot proceed and what can continue | Ask the responsible person a specific question through the team's agreed route |
| Urgent incident | Brief context only if appropriate | Use the incident or escalation process now, not the next check-in |
This table is an editorial suggestion, not a Slack or Teams rule. Posting in chat does not establish that someone saw it or agreed to own the request.
Fictional examples
All messages below are invented. Names and links are placeholders, not real people or projects.
Progress, not yet released:
Changed: the new address form passes the planned validation cases in the test build. Next: ask for review of the error messages. Need: no action from the wider team. Watch: this is not released yet. Details: [work item].
Blocked, with useful work still possible:
Changed: the export layout is ready for review. Next: test it with the final field list. Need: Morgan, can you confirm whether the customer code is required? The question is in [work item]. Watch: I can test the layout with sample data, but cannot finish the export check until that decision is made.
No major change:
Changed: the first approach did not reproduce the timeout; the tested cases are in [work item]. Next: test the larger sample. Need: no help yet. Watch: the cause is still unknown, so I do not have a reliable fix date.
Avoid turning "working on it" into a made-up percentage. A verified test, a reviewed draft or a named unresolved question gives readers something more useful.
Agree on the rhythm before automating
Atlassian's standup guide describes written Slack or work-board updates for distributed teams. Our suggestion is to pick one home for updates and a review window that suits the team. State whose timezone applies. Agree who follows up on requests and what counts as urgent. Do not assume an emoji means approval, ownership or a promised response time.
GitLab's communication handbook distinguishes an explicit request from a CC and says its people are not expected to reply outside planned working hours. Set your own team's expectations rather than assuming that copying or mentioning a person creates an obligation.
A simple manual post is enough to try the format. A bot is optional, and installing one can involve workplace approval, data access or cost. This guide does not require one. Keep customer data and restricted links within an audience allowed to see them.
If the update starts a longer discussion, link or thread the discussion according to your team's practice. When a decision changes the plan, update the work record and close the loop with the people affected. Do not leave the only final answer in yesterday's chat.
What this is, and is not
GitLab documents async standups in chat or issue discussions; its own engineering handbook also shows a weekly update format with progress, next steps, blockers and confidence. Atlassian suggests trying a short async check-in as a team experiment. These are examples, not evidence that every team should stop meeting.
A shift handoff transfers responsibility when one person stops and another starts. A deadline-risk update asks for action when a commitment may slip. A routine async update helps people coordinate ongoing work. Use the format that matches the decision instead of sending all three every day.
Sources checked October 31, 2026. Product-independent format, table and examples are editorial suggestions. No Slack or Teams account settings or notification delivery were tested for this draft.
Sources and limits
Checked October 31, 2026. This is an editorial format, not a tested productivity claim or a rule for Slack or Teams. The artwork is a conceptual illustration, not a screenshot.