How to Run a Standup Meeting: Agenda, Blockers and Examples
Run a useful standup with a shared work view, clear blocker follow-ups and a short outcome record. Learn how a general check-in differs from a Daily Scrum.
On this page
To run a useful standup meeting, review the shared work, identify what threatens the team's immediate goal, and agree the next actions or conversations. Keep the live discussion short, but do not save an urgent blocker for tomorrow's meeting. The outcome should be a clearer plan, not a list of everything each person did.
This guide covers a general team standup and distinguishes it from the Daily Scrum, which has specific rules. Use the meeting agenda templates if you only need a printable agenda; read on for facilitation, blocker handling and remote adaptations.
Standup meeting or Daily Scrum?
| Format | Purpose | Who decides how it runs? |
|---|---|---|
| General team standup | Coordinate interdependent work and surface problems | The team, according to its work and constraints |
| Daily Scrum | Inspect progress toward the Sprint Goal and adapt the plan | The Developers within the Scrum framework |
| Written team update | Share information people can read in their working hours | The team; someone must still respond to questions and blockers |
The official Scrum Guide defines the Daily Scrum as a 15-minute event for Developers, held every working day of the Sprint. Developers choose its structure around the Sprint Goal. The familiar “yesterday, today, blockers” questions are optional, not a required script. A Product Owner or Scrum Master working on Sprint Backlog items participates as a Developer.
An async update or weekly check-in can suit a general team. It is not an interchangeable replacement for the Daily Scrum while claiming to follow Scrum unchanged. The rest of this guide offers practical formats, not additional Scrum rules.
Prepare the work before the meeting
- Name the shared objective. For a delivery team, this might be “complete the tested checkout change.” A list of unrelated personal tasks gives people little reason to coordinate.
- Update the shared board or document. Make blocked work, review queues and dependencies visible before the call. Choose a view the team can scan together.
- Bring exceptions and help requests. Participants should know what has changed, which next step they intend and where help is needed. They do not need a rehearsed activity report.
- Agree how follow-ups happen. Choose where blockers are recorded, how urgent help is requested and who will arrange each discussion.
Standing is optional. Offer a format people can access comfortably, including seated attendance, text participation or captions where needed. Requiring cameras is not necessary to coordinate work.
Two ways to run the discussion
Walk the work
Start with items closest to completion, then inspect blocked or at-risk work. Ask:
- What needs to happen next for this item to move?
- Is a dependency, missing decision or review holding it up?
- Should the team adjust today's plan to support the shared objective?
This format helps when several people contribute to the same work. Avoid reading every ticket aloud. Focus on exceptions and changes that require coordination.
Use a short round when the board is not enough
Each person shares their intended contribution, relevant change and help needed. “Yesterday, today, blockers” can provide a starting prompt, but it should not become a compulsory recital.
Replace “I worked on the report” with “The report is ready for review; I need Jordan's check before I can send it.” The second update gives someone else a useful next action.
There is no universal team size or speaking allowance. With a larger group, a full round may consume the time before useful coordination begins. Change the view, attendance or work grouping rather than merely asking everyone to speak faster.
A practical 15-minute facilitation plan
The schedule below is a starting format for a general team standup, not a mandatory Scrum agenda.
| Time | Focus | Facilitator prompt |
|---|---|---|
| 0–2 minutes | Shared objective and important change | “What changed that affects our plan?” |
| 2–10 minutes | Work needing coordination | “What moves this forward, and who needs help?” |
| 10–13 minutes | Agree immediate adaptations | “Do we need to change who works on what?” |
| 13–15 minutes | Confirm follow-ups | “Who will talk, about what, and when?” |
Keep genuine planning decisions inside the conversation when they can be made briefly. Move lengthy diagnosis, design debate or a conversation involving only two people into a separate discussion. Before moving on, name its purpose, participants and next contact time; “take it offline” alone is not a plan.
Handle blockers without making the meeting the bottleneck
A blocker is an obstacle to progress: missing access, a failed test, an unavailable review, an external dependency or a decision nobody has made. People should raise urgent blockers when they arise instead of waiting for the next standup.
For each blocker, establish:
- Affected work: What is unable to move, and what does it put at risk?
- Help needed: Is this a decision, access request, specialist review or joint investigation?
- Next action: What will happen immediately after the meeting?
- Contact: Who has agreed to arrange that action, and when will the team hear back?
Assigning a contact does not mean blaming that person or making them solely responsible for a problem outside their control. If nobody can commit to resolving it yet, record the escalation or clarification action instead of inventing a resolution deadline.
Worked example: a blocked review
This is a fictional team example.
Vague update: “Still waiting on review. Same as yesterday.”
Useful update: “The checkout fix is ready, but the security review is pending. Priya and Lee will check the outstanding question after this call and post the outcome by 14:00 UTC. Until the required checks pass, the release stays unapproved.”
That record names the obstacle, the next conversation and the reporting time. It does not claim that review will pass or that the release will happen today.
Keep a short outcome record
Record what changes the plan or needs follow-through. You usually do not need a word-for-word archive of every update.
| Item | Current position | Agreed next action | Contact and next update |
|---|---|---|---|
| Checkout review | Security question unresolved | Priya and Lee review together | Priya; 14:00 UTC |
| Help article | Ready for copy review | Jordan checks the instructions | Jordan; date to confirm |
| Release | Approval pending | Reassess after required checks | No release time agreed |
Keep the record with the work so the team does not have to reconcile a board, an email and a chat message that disagree. At the next meeting, revisit unresolved items by their current state rather than repeating the entire history. For a more detailed action log, see how to track meeting action items.
Remote and async standups
For remote live meetings, use one shared work view and leave a way to contribute in text. Check that screen-shared content is readable; say the item name aloud instead of relying on a pointer. Choose a time that is workable across the team's hours, and revisit a schedule that consistently burdens the same people.
For a general team that chooses a written check-in, agree a response window and a route for urgent help. A channel full of unread updates does not coordinate anything.
Copyable async update
Shared objective: [goal]
My next contribution: [specific next step and work link]
Change or help needed: [dependency / decision / blocker, or none]
Response requested from: [person or team, if known]
Next update: [agreed time, or to be confirmed]
Use a short live conversation when written messages cannot resolve a dependency efficiently. If the team follows Scrum, evaluate any proposed change against its Daily Scrum requirements rather than labelling a different process compliant by default.
Diagnose a standup that is not helping
| Symptom | Check first | Try next |
|---|---|---|
| Everyone reports to the manager | Is the conversation about individual activity or the shared plan? | Have participants address the work and each other |
| The same blocker returns daily | Did anyone accept a concrete next action? | Record the help request, escalation and next update |
| The meeting always overruns | Is detailed troubleshooting consuming everyone's time? | Arrange a smaller follow-up and confirm its purpose |
| Updates repeat the board | Is there any exception or decision that needs live coordination? | Review changes and risks instead of reading tickets |
| Nobody asks for help | Are obstacles absent, misunderstood or uncomfortable to raise? | Discuss this privately and in a retrospective; do not assume laziness |
| Time zones make attendance costly | Does every person need to be in that live conversation? | Redesign general-team coordination; preserve Scrum requirements if applicable |
Review the meeting's usefulness with the team. Look at concrete outcomes: were blockers addressed sooner, did people know the next step, and did unresolved dependencies get a response? Do not treat attendance, speaking time or transcript length as a productivity score.
Use transcription only when it helps
A small outcome note may be sufficient. Paste the checked notes into the summary generator and choose Action items only if you want a draft action list. Supplied text goes to Anthropic for processing, and daily AI limits apply. Check the privacy policy and your organisation's requirements before submitting sensitive material.
If you need a fuller record, live transcription is a separate workflow: audio transcription runs on your device, while AI briefs process transcript text online. Check its automatic brief and optional email settings before capture, and inform participants as required. Review names, owners, dates and conditions before sharing any generated result. The tool does not update your work board or resolve blockers for you.
Frequently asked questions
Does every standup have to be 15 minutes?
That is the Daily Scrum timebox. For a general team check-in, choose a short, purposeful duration suited to the coordination needed. The test is whether the team leaves with a useful plan, not whether everyone fills a time allowance.
Who should facilitate?
A general team can choose or rotate a facilitator to keep the discussion focused and confirm follow-ups. In Scrum, Developers own the Daily Scrum; the Scrum Master is not required to collect status from them.
What should someone do if they miss it?
Keep their work status current and surface any urgent dependency through the agreed channel. Share the changed plan or follow-up record so absence does not leave them working from stale information.
Can a non-technical team run a standup?
Yes, when the team has work that benefits from frequent coordination. Use the team's own vocabulary and objective. Do not add a daily meeting simply because another team uses one.
Source and scope
The Scrum-specific distinctions above follow the official 2020 Scrum Guide, Daily Scrum section, checked for this revision. The facilitation schedule, diagnostic table, fictional examples and async template are editorial suggestions rather than requirements from that guide.