The daily standup is the most run meeting in software engineering — and, arguably, the most misunderstood. Teams schedule 15 minutes every morning, shuffle through updates one by one, and call it Scrum. But most standups aren't actually doing what they're supposed to do.
When done right, the standup is the heartbeat of a sprint: a brief daily pulse-check that keeps everyone moving in the same direction, surfaces blockers before they compound, and requires zero preparation. When done wrong, it's a slow-moving status report that drains the first hour of everyone's day.
This guide explains the format, facilitation technique, anti-patterns to kill, and when to go async — so your team can run a standup worth showing up to.
What the Daily Standup Is Actually For
Before fixing your standup format, get clear on the goal. The Scrum Guide defines the Daily Scrum as a 15-minute event for the developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. Two things stand out in that definition:
- It's for the developers, not the manager. The standup is a peer coordination meeting, not a report-up to leadership. If the team feels like they're updating a boss rather than syncing with colleagues, the meeting has already gone wrong.
- The sprint goal is the reference point. Every update should tie back to whether the team is on track for the sprint goal — not just whether individuals are busy.
The standup's job is to answer one question: Does anything need to change today to keep the sprint on track? Everything else — detailed technical explanations, solution discussions, stakeholder updates — happens elsewhere.
The Three Questions (and What They Really Mean)
The classic standup format uses three questions. They're simple, but each one has a specific purpose that teams often miss.
What did I complete since the last standup?
Not "what did I work on" — complete. Forces honesty about progress and reveals if stories are dragging on too long.
What am I working on today?
Creates accountability and surfaces overlap — two engineers unknowingly working on the same thing, or an engineer ignoring a higher-priority task.
Is there anything blocking my progress?
The most important question. A blocker raised here gets resolved today. A blocker not raised can silently kill a sprint for days.
Some teams modify the format. That's fine — the three-question structure is a starting point, not a sacred rule. What matters is that the meeting creates shared awareness and surfaces blockers quickly. If your modified format does that, keep it.
Walking the Board Instead
An alternative to the three-questions format is walking the board — going through sprint tickets from right to left (closest to done first) and discussing what's in progress, what's blocked, and what's ready to be pulled. This format is often faster for teams with a well-maintained board because it grounds the conversation in actual work rather than individual updates. It also makes it easier to spot WIP pile-ups and stories aging in a column.
The Standup Format That Actually Works
Here's a minute-by-minute breakdown of a tight, effective standup for a 6-person team targeting 12 minutes total:
The "after-party" framing is one of the most underrated standup techniques. It gives people who have more to say a channel to say it without holding the whole group hostage. And critically, it makes the end of the standup feel like a release rather than an interruption.
How to Facilitate (Without Micromanaging)
Good facilitation is nearly invisible. A well-facilitated standup feels like a natural conversation that happens to be fast and useful. Here's what that looks like in practice:
Set the Pace Without Being the Traffic Cop
Your job is to keep things moving — not to police every word. If someone is going long, a simple "let's park that for the after-party" is enough. If the team is talking about a solution rather than identifying a blocker, redirect: "What do you need to unblock? Who can help?" You're steering, not judging.
Stand Up Physically (When In-Person)
This one sounds obvious but teams forget it. Standing up creates a natural physical timer — people get uncomfortable after 10–12 minutes and wrap up. Seated standups drift toward 25-minute meetings. If your team is remote, the equivalent is keeping video on with camera-height framing that signals "this is a quick meeting, not a sit-down."
Don't Go in a Fixed Order
Round-robin (alphabetical, clockwise, same person always first) slows the meeting and creates passive waiting. Instead, let the team self-organize: "Who wants to go first?" or "Let's start from the right side of the board." Whoever is closest to done on a key story often has the most time-sensitive update, so starting there makes flow sense.
Listen for Dependencies, Not Just Status
While people are talking, you're listening for: "Is anyone waiting on someone else's output?" If Person A is starting a task that depends on Person B finishing something, flag it. That dependency is a blocker waiting to happen. Surface it now while everyone is in the room.
"The best standup facilitators I've worked with don't say much. They listen carefully, spot when a conversation is about to go 5 minutes deep, and redirect before the room loses focus." — Senior Scrum Master, fintech team of 8
Anti-Patterns That Kill Standups
Most bad standups suffer from one or more of these patterns. Identify which ones apply to your team and fix them one at a time.
| ❌ Anti-Pattern | ✅ Fix |
|---|---|
| Status report to the manager — People address their updates to the SM or EM, not the team | Physically move so the manager is not at the "head" of the group. Have team members face each other, not leadership |
| Problem-solving in the meeting — "I'm blocked on the auth issue" → 10-minute debugging session | Cut it at 30 seconds: "Let's take that offline. Who should join that conversation? 9:30 work?" Schedule it immediately |
| No one knows what the sprint goal is — Updates are disconnected from any shared objective | Print the sprint goal and stick it in the room. Read it at the start of every standup until the team has it memorized |
| People join unprepared — Thinking through their update live, creating dead air | Have team members check the board for 2 minutes before standup. A Slack reminder 5 min before helps |
| The "I'm fine" update — "Working on the same ticket as yesterday, no blockers" every single day | Prompt: "What specifically will you finish today?" If the answer is the same three days running, that story might need replanning |
| Standup as the only sync — Team relies on standup for all coordination, so it keeps expanding | Establish other lightweight channels: a Slack thread for async blockers, a quick DM for two-person coordination. Standup should be the summary, not the only channel |
| Running over every day — 15 minutes drifts to 25, then 35 | Set a visible timer. When it hits 15:00, the facilitator says "We're over — let's continue with whoever is needed." Walk away |
When to Go Async
The sync standup is not the only valid format. For many teams — especially distributed ones or teams that do a lot of deep, uninterrupted work — a well-structured async standup outperforms the daily meeting.
⚡ Sync Standup — Best When
- Team is co-located or in overlapping timezones
- Sprint has active blockers that need same-day resolution
- Team is early-stage and still building shared context
- Work is highly interdependent and handoffs are frequent
- You're mid-sprint and energy or morale needs a moment of human contact
📝 Async Standup — Best When
- Team spans 3+ timezones with no clean overlap window
- Engineers regularly need 3–4 hour uninterrupted blocks
- Work is relatively independent and blockers are rare
- Team is senior and self-directed — coordination is low-overhead
- Current sync standup consistently fails to produce action items
Running a Good Async Standup
An async standup that's just "post your three questions in Slack" usually degrades into noise that nobody reads. Make it work by:
- Using a dedicated channel or tool — not buried in general chat. Projiq's standup feature or a pinned Slack thread with a bot prompt works well.
- Setting a deadline — posts due by 10am in each person's local time. Consistency is what makes it useful.
- Having someone actually read and respond to blockers — ideally the SM or TL acknowledges blockers with a reply and resolution plan within the hour.
- Doing a weekly sync standup — even async-first teams benefit from one live meeting per week to maintain human connection and catch anything that fell through the async cracks.
Remote and Hybrid Standup Tips
Remote standups have their own failure modes. The classic issues: people talking over each other, awkward silences, cameras off so you can't read the room, and the meeting drifting because there's no physical discomfort to end it.
- Video on by default. Not a surveillance move — it's a connection move. Reading expressions lets facilitators catch when someone is struggling and not saying so.
- Use a talking order for remote standups. Unlike in-person, self-organizing doesn't work as well over video because of lag. Go alphabetically or board-order, but keep it fast.
- Share the board on screen. If you're walking the board, screenshare the Projiq sprint board so everyone is literally looking at the same thing. It cuts ambiguity instantly.
- Use reactions, not interruptions. Train the team to use emoji reactions (👍 for "got it," ❓ for "can we discuss this") instead of talking over people. Async-style communication tools even in sync meetings reduce friction.
- Set a hard end-time in the calendar invite. Zoom and Meet don't naturally end meetings. A 9:00–9:15 block with no buffer teaches the team that 9:15 means done.
How to Know If Your Standup Is Working
You don't need a formal survey to assess standup health. Watch for these signals over two to three sprints:
Signs of a Healthy Standup
- Consistently finishes at or under 15 minutes
- Blockers raised in standup are resolved the same day
- Team members reference each other's updates ("Oh, you're working on that — I just finished the API it depends on")
- People arrive prepared and rarely repeat yesterday's update word-for-word
- Engineers stay for the after-party voluntarily rather than being corralled
Signs It Needs Work
- People look at their phones or multitask during others' updates
- The same blockers appear day after day without resolution
- One person (usually the SM or EM) does most of the talking
- Engineers frequently say "same as yesterday" without pushback
- The meeting ends and nobody does anything differently than they would have without it
The simplest retrospective question: "Did anything you learned in standup today change what you did this morning?" If the answer is "no" for most people most days, the standup format needs to change. See our sprint retrospective templates for structured ways to surface this feedback from the team.
Standup vs. Sprint Planning
Teams sometimes blur standup with mini sprint planning — re-discussing task assignments, debating priority, or pulling new stories into the sprint during the daily meeting. This is a sign that sprint planning wasn't done well enough, not that standup needs to absorb more scope.
Keep standup focused on today's execution. If the sprint goal has materially changed, call an explicit replanning session rather than retrofitting it into the standup. A rushed 5-minute replanning discussion embedded in standup almost always produces worse decisions than a dedicated 30-minute session with the board in front of everyone. Our sprint planning guide covers how to run a planning session that sets standup up for success.
"The daily standup and sprint planning are solving different problems. Planning answers 'what should we build this sprint?' Standup answers 'how is today going?' Mixing them is like using a hammer as a screwdriver — you'll eventually drive the screw, but badly."
Run Standups From Your Sprint Board
Projiq's sprint board shows every story's status in real time. Walk the board in standup, update blockers in one click, and let engineers post async updates before the meeting even starts.
Start Free — No Credit Card Required