The Stand-Up Meeting: Format, Questions, and Timing
A stand-up meeting is a short, recurring team sync, usually held once a day, where each person shares where their work stands and flags anything blocking them. It is deliberately brief. The name comes from the original practice of everyone literally standing up so the meeting stays uncomfortable enough to end fast.
Done well, a stand-up keeps a team aligned without eating the morning. Done badly, it becomes a status-report ritual that people dread. That is not a hunch: the largest survey of the practice found developers split almost evenly between people who value it and people who resent it, with a group-average rating that lands on “neutral.” The difference between the two camps is almost entirely in how the meeting is run.
Where the stand-up comes from
The stand-up predates Scrum. The Agile Alliance traces the earliest written “StandUpMeeting” pattern to Jim Coplien in 1993, drawn from his study of the unusually productive Borland Quattro Pro team, which relied on near-daily meetings. The idea then became a named practice in Extreme Programming: the XP “daily stand up meeting” rule prescribed a short daily gathering to replace a pile of longer meetings, and the standing posture existed for one reason, to make the meeting short by making it slightly uncomfortable to linger.
That instinct sits on top of a deeper agile idea. The sixth principle behind the Agile Manifesto states that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” A daily stand-up is that principle compressed into fifteen minutes: get the people doing the work in one place, briefly, every day.
Scrum then made the practice famous by formalizing it as the “daily scrum.” The format has since spread far beyond software. Marketing teams, operations teams, and leadership groups now run daily or a few-times-a-week stand-ups because a tight recurring check-in scales well across almost any kind of work.
What the Scrum Guide actually says
Because most teams inherited the stand-up through Scrum, it is worth reading the source rather than the folklore around it. The 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland defines the daily scrum tightly, and two of its constraints are the ones teams most often break.
It is 15 minutes, for the developers. The guide describes a “15-minute event for the Developers of the Scrum Team” and says it is held “at the same time and place every working day of the Sprint” to reduce complexity. The people doing the work are the audience. It is not a slot for the Scrum Master or Product Owner or a manager to collect status, and Scrum.org states plainly that “the Daily Scrum is not a status meeting.”
Its job is to change the plan, not to log the past. The stated purpose is to “inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.” In plain terms: the meeting exists to decide what happens in the next 24 hours, not to narrate the last 24. A stand-up that ends without anyone changing what they were going to do next is a stand-up that skipped its own point.
Both constraints — for the doers, about the future — are what separate a real stand-up from the status-report ritual it so easily degrades into.
The three questions, and why Scrum dropped them
The stand-up most people picture has each person answer three questions:
- What did I do since the last stand-up?
- What will I do before the next one?
- What is blocking me or slowing me down?
The third question is the one that matters most. The first two exist mainly to surface the third. A stand-up where nobody ever raises a blocker is usually a stand-up where people have stopped being honest, not a team with no problems.
Here is the part most guides get wrong: the current Scrum Guide no longer prescribes these questions at all. Earlier versions offered them as a suggested structure, but the 2020 revision removed the prescribed questions entirely, leaving the developers free to choose whatever structure and technique keeps the meeting focused on progress toward the sprint goal. The reason is exactly the failure mode teams complain about: treating the three questions as a rigid script turned the event into three sequential rounds of status reporting, addressed to the facilitator instead of across the team. The questions are a useful starting scaffold for a team that has never run a stand-up. They are not the meeting, and outgrowing them is a sign of a healthy team, not a broken one.
What research says makes stand-ups useful or wasteful
The daily stand-up is one of the few agile practices with real empirical study behind it, and the findings are usefully blunt.
The foundational work is Viktoria Stray, Dag Sjøberg, and Tore Dybå’s grounded-theory study of the daily stand-up, published in the Journal of Systems and Software in 2016. The researchers observed 79 stand-ups across 12 teams and interviewed 60 people. They found the meeting’s genuine value comes from information sharing and the chance to surface and solve problems together, but that the same meetings were frequently experienced as a waste of time and an interruption when they ran long, when updates were relevant to only a couple of people while everyone else waited, and when attitudes toward the ritual had already soured.
A companion survey, Stray, Nils Brede Moe, and colleagues’ study of 221 developers presented at XP 2017, quantified how divided practitioners are. Around 70% of respondents attended daily stand-ups, and the practice was used by roughly 87% of teams doing agile — but the average perceived value came out essentially neutral, and only about a fifth of respondents actually chose the neutral middle rating. In other words, most people had a strong opinion in one direction or the other; the “neutral” average was two crowds cancelling out. Notably, junior developers rated stand-ups most positively, while senior developers and members of large teams rated them most negatively. That pattern is a useful diagnostic: if your most experienced people quietly dread the stand-up, the meeting is probably running as status theater rather than coordination.
The same researchers’ follow-up, “Daily Stand-Up Meetings: Start Breaking the Rules” in IEEE Software, draws the obvious conclusion — that there is no single correct stand-up format, and teams should adapt the timing, structure, and even the medium to their context instead of defending a ritual. A stand-up is a tool for a specific job. When it stops doing that job, changing it is the point, not a compromise.
Ideal length, time, and format
Length. Cap it at 15 minutes, per the Scrum Guide. For a team of five to nine people, that is roughly 90 seconds each plus a little slack. The research is clear that overrun is the single most common source of resentment, so if the meeting regularly runs long, treat it as a signal about content, not a scheduling problem.
Time. Pick a consistent time and hold it every working day. Many teams run it mid-morning rather than first thing, so people who arrive at staggered times are all present and have had a moment to see what landed overnight. Same time, same place, every day, is the whole point — the guide names consistency as the mechanism that “reduces complexity.”
Attendance. Keep the circle small. The people actively doing the work attend and speak. Observers can listen, but the moment a stand-up becomes a room of stakeholders waiting for a report, it stops being a stand-up. The senior-developer resentment the survey found is often this exact drift.
Take blockers offline. When a topic needs more than a sentence or two of discussion, name it, note who needs to talk, and move on. The people involved sort it out right after. This one habit does more to keep stand-ups short — and to stop the “updates only two people care about” problem the grounded-theory study flagged — than any timer.
A sample stand-up script
Here is a simple format you can run as-is:
Facilitator: “Morning, everyone. Quick round, then we take the deep stuff offline. Priya, kick us off.”
Priya: “Yesterday I finished the onboarding email revisions. Today I’m starting the pricing-page copy. No blockers.”
Marcus: “Yesterday I pushed the API fix to staging. Today I’m testing it against the sandbox. I’m blocked, I need the updated credentials from Dana.”
Facilitator: “Dana, can you and Marcus sync right after?”
Dana: “Yep. Yesterday I closed the two support escalations. Today I’m on the credentials plus the Q3 report. No other blockers.”
Facilitator: “Great. Marcus and Dana, you’ve got the creds. Everyone else, that’s a wrap.”
Under three minutes for a small team, one blocker caught and assigned, no rabbit holes. That is the target.
Remote and async stand-ups
Distributed teams run stand-ups two ways.
Live remote stand-ups work like the in-person version over video. The rules tighten: cameras on if the team agrees, one speaker at a time, and the facilitator watches the clock harder because remote meetings sprawl more easily. A shared board on screen helps everyone follow along. Good meeting scheduling apps keep the recurring slot pinned across time zones, and a few free meeting tools handle the video and shared-board side without added cost.
Async stand-ups drop the live meeting entirely. Each person posts their update in writing, in a shared channel or tool, on their own schedule within a window. This is the better fit for teams spread across many time zones and, notably, for the large teams that the survey found rate live stand-ups most poorly — a written thread scales to a big group far better than a round-robin does. GitLab, one of the largest all-remote companies, treats this as default in its public handbook on asynchronous communication, running written, issue-linked standups instead of a synchronous call; the company credits its async-first approach with cutting meeting time substantially while keeping work moving.
Async does trade the real-time back-and-forth for flexibility and a written record — and that trade is a real one, given the Agile Manifesto’s own bet that face-to-face conversation carries information most efficiently. The catch is logistical: async stand-ups live or die on collection. If updates trickle in late or get missed, the sync quietly stops happening. That is a process problem, not a culture problem, which means it is fixable with the right prompt-and-collect mechanism rather than more nagging.
Anti-patterns that kill stand-ups
Status theater. The stand-up becomes a performance for a manager instead of a team coordinating with each other. People report up rather than talk across — the precise drift the Scrum Guide warns against by calling this a developers’ event, not a status meeting. Fix it by having people address the team and by keeping managers in listen-only mode.
Going long. Fifteen minutes becomes forty because one problem gets solved live while eight people watch. This is the most-cited waste in the research. Take it offline the instant a topic needs discussion.
Reciting a diary. People narrate every task they touched yesterday. Only what affects the plan or the team matters. “Yesterday was heads-down on the report, no change to the plan” is a complete update.
No blockers, ever. If nobody raises an obstacle for weeks, the stand-up has become ritual. Ask directly, and make it safe to say “I’m stuck.”
Skipping the point. Reading updates without adapting the plan is just a meeting. The daily scrum exists to change what happens next, not to log what already did.
Tips to keep them useful
- Prepare a one-line answer before you arrive. A stand-up is not the place to figure out what you did.
- Have a facilitator, and rotate it. Someone owns the clock and the “take it offline” call. Rotating the role spreads ownership.
- Use a shared board. Walk the work, not the people. Reviewing the board top to bottom keeps focus on what needs to move rather than on individual performance.
- Kill it if it stops earning its slot. A stand-up that consistently produces nothing new should be cut to a few times a week or switched to async — exactly the “break the rules” adaptation the research endorses. The meeting serves the team, not the other way around.
- Separate stand-ups from deeper syncs. A stand-up is not a planning session, a retro, or a one-on-one. Keep a running meeting agenda for the bigger discussions so they don’t leak into the daily.
For anything longer than a stand-up, capturing decisions matters. A meeting minutes template keeps larger syncs from evaporating, and AI tools for meeting prep can pull the context together before you meet.
Carly is an AI executive assistant that works across email, calendar, tasks, CRM, and 200+ integrations to actually execute work rather than just remind you about it. For distributed teams, this is where the async stand-up problem gets solved: Carly can hold the recurring stand-up slot, prompt each person for a written update on a set schedule, and compile the responses into one digest the whole team can read, so the sync happens reliably without adding another live meeting to the calendar. Carly starts at $35/month.
FAQ
How long should a stand-up meeting be? No more than 15 minutes, and often less for small teams. The 15-minute cap comes directly from the Scrum Guide’s definition of the daily scrum. Research on the practice found that running long is the single most common reason developers come to resent stand-ups, so if yours regularly overruns, you are solving problems live that should be taken offline.
What are the three stand-up questions? What did I do since the last stand-up, what will I do before the next one, and what is blocking me. The third is the most important. The 2020 Scrum Guide removed these questions as a prescribed format, because teams tended to turn them into rote, upward status reports, so treat them as a scaffold for a new team rather than a permanent script.
Are daily stand-ups actually worth it? The evidence is genuinely mixed. In a survey of 221 developers, opinion was sharply polarized rather than uniformly positive, with junior developers most in favor and senior developers and large teams most against. The takeaway from the research is not “stop doing them” but “adapt them” — match the format to the team, and drop or convert the meeting when it stops producing decisions.
What is an async stand-up? An async (asynchronous) stand-up replaces the live meeting with written updates that each person posts on their own schedule within a set window. It suits teams across many time zones and large teams that scale poorly in a live round, at the cost of real-time discussion. It only works if updates are reliably collected.
Do stand-ups have to be daily? No. Daily is the classic cadence and the origin of the name, but many teams run stand-ups two or three times a week. Match the frequency to how fast the work changes and how much coordination the team actually needs.
Related: Meeting agenda template · Meeting minutes template · How to run one-on-one meetings · Best AI tools for meeting prep · Best meeting scheduling apps
Ready to automate your busywork?
Carly schedules, researches, and briefs you—so you can focus on what matters.
See what people say
"Before Carly, I relied on a Calendly link, but the whole process felt impersonal and not very professional. Carly changed that by handling all the back-and-forth, so I'm no longer stuck in endless email threads trying to line up schedules.
Now Carly reaches out to candidates, shares my real-time availability, lets them pick a slot, then sends a Zoom link and drops it straight into my calendar. She sends reminders to both of us before each call, which has significantly reduced no-shows and last-minute confusion.
On top of scheduling, Carly acts like a full executive assistant, sending me my schedule the night before so I can prepare for each call. It reminds me of the old x.ai assistant, but Carly is noticeably smarter, faster, and better suited to my healthcare recruitment business."
