What is a standup meeting?

A standup (or daily scrum) is a brief, time-boxed meeting where each team member shares what they completed yesterday, what they plan to do today, and what is blocking them. The goal is to surface blockers early and keep the team aligned, not to report status to a manager.

Why should we use a flowchart for a standup meeting?

A flowchart makes the meeting structure explicit: each person goes in order, blockers trigger a parallel deep-dive track (scheduled after standup, not during), and the meeting has a clear exit condition (all people done = standup over). It prevents standups from devolving into problem-solving sessions that balloon from 15 minutes to an hour.

How long should a standup take?

A standup should be 5–15 minutes for a team of 5–10 people. That's roughly 1 minute per person. If a blocker needs 10 minutes to unblock, note it and solve it in a separate conversation after standup so the meeting stays focused and short.

How do I use this diagram to run a better standup?

Print it or share it on screen at the start of the meeting. Call out the structure: 'We'll go around the circle, each person gets ~1 minute, if there's a blocker we note it and deep-dive after standup ends.' The visual flow helps remote teams and makes it clear that silence is OK — nobody needs to fill time. Visual edits regenerate clean Mermaid code.

All templates

Flowchart template

Team standup meeting flow

Daily standups: sharing updates, surfacing blockers, planning next steps.

Customize with AI Use this template

The daily standup is where teams either stay synchronized or silently drift out of sync. The best standups are short, frequent, and ruthlessly focused: each person says what they did, what they're doing, and what is blocking them. Nothing else. A 15-minute standup on 10 people means each person gets roughly 90 seconds to talk. If you spend 10 minutes debugging a blocker during standup, the meeting balloons to an hour and people stop paying attention.

This template enforces that discipline. It shows the meeting structure: round-robin through team members, note any blockers (don't solve them during standup), and once everyone has spoken, surface and assign owners for the blockers. The key insight is the decision diamond: if someone reports a blocker, you don't stop the standup to debug it — you note it and deep-dive separately, so the standup stays under 15 minutes. This distinction between "surface the blocker" (during standup) and "solve the blocker" (in a separate sync after standup) is the difference between a standup that keeps teams aligned and one that becomes a problem-solving session where half the team zones out.

Why run standups at all? Because teams that don't communicate daily drift apart quickly. Standups are the pulse check: they surface misalignment early (Person A finished the API contract spec, but Person B is already halfway through the implementation with a different contract) and blockers before they fester for a week. The standup also creates psychological safety: everyone on the team knows what everyone else is working on, so side-channel assumptions ("I thought you were working on X") evaporate.

The structure matters. By requiring each person to speak (even if it's "nothing new since yesterday"), you keep people engaged. By catching blockers and assigning owners (not solving them during standup), you make it clear that problems are the team's responsibility, not individual firefighting. By keeping it short, you create urgency: people learn to be concise and on-topic. Standups that run 45 minutes signal that time is not valued; standups that run 10 minutes signal that the team respects each other's time and focus.

When to use this template

Launching a team standup ritual — share this diagram when you introduce daily standups so the team understands the format and what "blocker" means (something genuinely blocking progress, not a question to ask during standup).
Remote-team coordination — video standups can easily balloon and derail. Post this diagram in your team Slack channel so async standups (threads, voice memos) follow the same structure and don't drift into ad-hoc problem-solving.
Onboarding new team members — walk them through the diagram on day one so they understand how the team communicates daily progress and flags issues before they surprise you mid-sprint.
Standup dysfunction diagnosis — if your standups are running long, derailing into tangents, or people are tuning out, walk through this diagram and identify where the ritual drifted (people solving blockers during standup instead of noting them, people giving status reports instead of updates).

How to adapt it

Customize the meeting structure to your team size and timezone distribution:

Large teams (15+ people) — run separate standups per sub-team or split into parallel tracks (backend standup, frontend standup) to keep each under 15 minutes.
Async standups — replace "Person 1 speaks" with "Person 1 posts thread" so distributed teams can participate without synchronized real-time calls. The structure stays the same: update, plan, blocker.
Add sprint metrics — after the blocker review, add a step that calls out sprint progress: velocity trending, burn-down, or release milestone status, so the standup becomes a 15-minute pulse check on both progress and alignment.
Standup health check — once a week, after the standup, ask: "Did anyone feel rushed? Did we solve any blockers during standup instead of after?" Use the feedback to adjust the next standup.

Because the visual editor writes clean Mermaid, you can sketch standup variations — sync vs. async, small team vs. large, blocker-focused vs. metrics-driven — and still export text for your wiki or docs. Share the diagram with your team so everyone understands the expectation.

The blocker follow-up sync is where real problem-solving happens. After standup, group similar blockers and assign owners: if Person A and Person B both reported they're waiting on the API contract spec, assign Person C (the backend lead) to unblock both. The follow-up should be time-boxed too: 5 minutes to debug, or schedule a deeper async investigation. If the blocker is hard and will take 30 minutes to resolve, don't solve it live — assign it to a ticket and move on. The distinction between "standup" (status + surface blockers) and "blocker follow-up" (solve blockers) is how you keep momentum high while staying coordinated.

Metrics and cadence vary by team. Some teams do standups daily (sync, real-time). Some distributed teams do async standups (threads posted to Slack each morning, read asynchronously). Some teams do standups 3x a week (Monday/Wednesday/Friday) if they have low velocity or are in maintenance mode. The structure stays the same regardless: update, plan, blocker. Experiment with cadence to find what keeps your team aligned without creating standup fatigue. If standups are running long and people are tuned out, the fix is usually: "We solved two blockers during standup that we should have parked; let's time-box blocker discussion to 2 minutes next time." Small structural changes often fix entire problems.

Mermaid code

Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.

flowchart TD
    A[Standup starts] --> B[Person 1: Yesterday + Today]
    B --> C{Blocker?}
    C -->|Yes| D[Note blocker for deep dive]
    D --> E[Next person]
    C -->|No| E
    E --> F{All team members done?}
    F -->|No| B
    F -->|Yes| G[Review blockers list]
    G --> H{Any blockers?}
    H -->|Yes| I[Assign owner + time box]
    I --> J[End standup]
    H -->|No| J

Frequently asked questions

What is a standup meeting?: A standup (or daily scrum) is a brief, time-boxed meeting where each team member shares what they completed yesterday, what they plan to do today, and what is blocking them. The goal is to surface blockers early and keep the team aligned, not to report status to a manager.
Why should we use a flowchart for a standup meeting?: A flowchart makes the meeting structure explicit: each person goes in order, blockers trigger a parallel deep-dive track (scheduled after standup, not during), and the meeting has a clear exit condition (all people done = standup over). It prevents standups from devolving into problem-solving sessions that balloon from 15 minutes to an hour.
How long should a standup take?: A standup should be 5–15 minutes for a team of 5–10 people. That's roughly 1 minute per person. If a blocker needs 10 minutes to unblock, note it and solve it in a separate conversation after standup so the meeting stays focused and short.
How do I use this diagram to run a better standup?: Print it or share it on screen at the start of the meeting. Call out the structure: 'We'll go around the circle, each person gets ~1 minute, if there's a blocker we note it and deep-dive after standup ends.' The visual flow helps remote teams and makes it clear that silence is OK — nobody needs to fill time. Visual edits regenerate clean Mermaid code.

Related templates

State

Retrospective action items state machine

Tracking action items from retrospective through closure.

Flowchart

Bug triage workflow

Classify, prioritize, and assign incoming bug reports systematically.

Flowchart

Feature request prioritization workflow

Intake, triage, prioritization, and roadmap placement.