Just after the morning coffee, a team of eleven gathers by the task board. The first speaker walks through yesterday’s tickets one by one, facing the team lead. So does the second. By the eighth, the lead is glancing at the clock, a tester has waited ten minutes to mention the bug blocking her, and the quarter-hour meeting is heading for its fortieth minute.

A daily stand-up earns its 15 minutes when it is a short planning conversation between teammates about today’s work and what stands in its way, not a round of status reports to a manager. Research on real software teams led by Viktoria Stray found that stand-ups feel like wasted time when they turn into status reports to whoever runs them, and earn their time when teammates talk to each other about the day ahead and what is blocking it. In practice:

1. Skip yesterday: talk about today and what is blocking you
2. Talk to each other, not to the facilitator
3. Settle small problems on the spot and move bigger ones to afterwards
4. Keep the group small enough that everyone’s work matters to everyone
5. Hold it where it breaks the day least, such as just before lunch
6. Meet as often as the work needs, not every day by default

What a daily stand-up is for

A daily stand-up exists so a team can adjust today’s plan together, not so a manager can hear what happened yesterday. The Scrum Guide, the framework document by Ken Schwaber and Jeff Sutherland that defines Scrum, describes its Daily Scrum as a 15-minute event where the people doing the work check progress toward the sprint goal and produce a plan for the next day.¹

When you hear that a colleague will spend the morning on the pricing page, you can tell her now that the discount wording is still with legal, before she builds on it. Each person hears what the others intend and adjusts their own plan to fit.² That only works when people’s work depends on each other; a meeting where nobody changes course after hearing the others is a report read aloud.

Many teams know it as three questions from earlier Scrum texts: what I did yesterday, what I will do today, and what is in my way.² The current guide leaves the format to the team.¹

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.

Standing is part of the name for a reason: in a 1999 study comparing standing and seated groups, those that met sitting down took about a third longer than groups that stood, and made no better decisions.³ Standing may trim the clock, but it cannot rescue a meeting filled with the wrong talk. Faults any meeting can have, such as late starts and missing agendas, are the subject of why meetings fail and what meeting science shows; this guide stays with the one meeting many teams hold daily.

A quick test follows from all this. After the stand-up, has anyone’s plan for today changed? If not, the meeting is doing a job a written update could do.

Why stand-ups feel longer than they are

Stand-ups feel long, whatever the clock says, when they become status reporting: people recount yesterday in detail, speak to whoever runs the meeting, and leave little room for the quick problem-solving people value. That is the central finding of nearly a decade of research on software teams by Viktoria Stray, Nils Brede Moe and Dag Sjøberg of SINTEF and the University of Oslo.²

The study

Limited evidence

Sitting in on 102 stand-ups: Stray, Moe and Sjøberg's case study

The observed stand-ups averaged about 12 minutes, but lengths ranged up to 24 minutes. In the transcribed meetings, about 34% of the talk answered the three standard questions and almost as much, 31%, went to discussing problems and making decisions, the benefit interviewees mentioned most often. Recounting yesterday took the largest share of the three questions and was the part people least wanted. When a facilitator handed out turns and everyone spoke to that person, the meeting often became a status report; when team members spoke to each other, it became a discussion.²

So the clock is rarely the real problem; what fills the time is. The caveat matters: this is qualitative research inside four software companies, and the fixes it recommends were tried by teams the researchers were helping, not tested against teams that carried on as before.

Why does yesterday bloat? Nobody knows exactly what the others need to hear, so people include everything, and a daily report invites self-justification: the long account of why a task took longer than planned.² Picture an analyst who spent the day on a stubborn data join. Her two-minute account of it helps nobody; the one sentence that matters is that the dashboard will be a day late, which the product owner needs to hear now.

Report

• Everyone speaks to the facilitator
• Yesterday, in detail
• People tune out until their turn

Discussion

• Teammates answer each other
• Today’s plan and what blocks it
• Small problems settled on the spot

A warning sign to listen for: when nearly every sentence is addressed to one person, you are running a status meeting, whatever the calendar calls it.

How to run a daily stand-up in 15 minutes

Run it as a short planning conversation among the people whose work depends on each other, at a time that breaks the day least. The steps below come mainly from recommendations Stray and colleagues developed with the teams they studied, and from the Scrum Guide.

1. Skip yesterday: talk about today and what is blocking you

In Stray’s observations, problem-solving rarely started from a recap of yesterday; it started when someone said what they would do today or named an obstacle. The researchers report that none of the teams they worked with brought the yesterday question back after trying without it.² Status still matters, so put it where people can read it: a shared task board, such as a simple kanban board, or a short written update.

2. Talk to each other, not to the facilitator

Stand in a circle or face the board, not the lead. Stray and colleagues suggest rotating the facilitator role so the meeting stops orbiting one person, and giving everyone roughly equal time, since the last speakers were often the ones cut short. If some people join remotely, use video: in the same study, teams whose facilitators used video instead of audio alone had more discussion-style meetings.²

The Scrum Guide makes a related point: the Daily Scrum is an event for the people doing the work, and a Scrum Master or Product Owner takes part as one of them when actively working on items in the plan.¹

3. Settle small problems on the spot and move bigger ones to afterwards

Quick problem-solving was the benefit interviewees mentioned most often, even when a fix took only a minute.²

Myth

A proper stand-up never discusses problems; it only answers the three questions.

Fact

In the observed teams, short problem-solving was the benefit people mentioned most often. The fix is to keep it brief, not to ban it.

The trouble starts when two people debate a design while seven others wait. A workable rule: if a question can be settled in about a minute, settle it; if not, name who needs to talk and let them stay behind. The Scrum Guide notes that developers often meet during the day for more detailed discussions.¹

4. Keep the group small enough that everyone’s work matters to everyone

Size works against a stand-up. In Stray’s observations, the more people attended, the less time each had to take part, members were generally less satisfied with large meetings, and larger teams more often slid into reporting. When most people’s work does not touch most others’, listeners have little reason to follow a turn that is not theirs. The researchers suggest such a team splits into smaller groups that do work together daily and brings everyone together less often.² In a 2017 survey of developers, teams of 12 or more were most strongly linked to negative views, a finding from an extra analysis the researchers ran after the main results.⁴

5. Hold it where it breaks the day least, such as just before lunch

In Stray’s study, early-morning stand-ups were often delayed a few minutes by people arriving late, and many team members saw the meeting as an interruption of their work. Some held off starting hard work until the meeting was over. The researchers suggest meeting just before lunch, which folds two breaks into one, and report that teams widely adopted and appreciated the change.² Every break costs more than its own minutes, which is why the cost of an interruption is worth knowing when you pick the slot.

6. Meet as often as the work needs, not every day by default

Seniors in Stray’s teams, who often knew what was going on already and whose complex tasks moved too slowly to report on daily, tended to value the meeting less than juniors. Small teams sitting together and talking all day may not need a daily meeting at all; the researchers suggest three or four a week can be enough for a team that already communicates well.² Formal Scrum does set the event for every working day, so a Scrum team that changes this is choosing to adapt the framework.¹

WiserHours

A stand-up tune-up

• Status is on the board or in a written update, not in the meeting
• Each person names today’s work and anything blocking it
• People face each other, and the facilitator role rotates
• Anything longer than a minute gets an owner and a follow-up
• Only people whose work overlaps are in the group
• The time and frequency suit the team, not the template

Find this checklist online:
https://wiserhours.com/meetings/daily-stand-up/#checklist-daily-stand-up-routine

Does a daily stand-up help a team at all?

Probably, when it runs as a team conversation, but the research base is smaller than the format’s popularity suggests. Opinion is split rather than lukewarm: in that 2017 survey, whose respondents were recruited from two Reddit programming forums, most who attended stand-ups were clearly for or against them, with junior developers the most positive and senior developers and members of large teams the most negative.⁴

A 2016 grounded theory study of 12 teams by the same group shows what divides the camps: its abstract names information sharing and the chance to solve problems as the main sources of positive attitudes, and status reporting to the manager, meetings held too often and meetings running too long as the main sources of negative ones.⁵

The strongest test so far comes from Sarah Rietze and Hannes Zacher of Leipzig University. People in agile teams answered their survey twice, about six weeks apart: those who reported more consistent stand-ups felt safer speaking up in their team at the second wave, and that sense of safety went with higher ratings of their satisfaction and their team’s performance. In a small experiment, student teams randomly assigned to add brief stand-ups (the classic three questions, yesterday included) to a five-day project reported more of that safety than teams without them.⁶

Psychological safety, the sense that it is safe to take interpersonal risks in a team, such as raising a problem, is one of the conditions researchers link to effective teams and how they work. Rietze and Zacher suggest stand-ups may build it by giving a team regular, structured talk and a set place where obstacles are raised and teammates help each other.⁶ Think of a new hire stuck on a login error: mentioning it where colleagues name their snags every morning costs far less than interrupting a senior engineer out of the blue.

The authors list the limits themselves. Nearly every measure was a self-reportself-report: A measure in which people describe their own behavior, feelings or circumstances, usually by answering a questionnaire. When the same person supplies both of the things being compared, shared habits of answering can make the link between them look stronger than it is.Full entry in the glossary, the stand-up teams in the experiment also spent more time together, and five days of student teamwork is not a year in an established team.⁶ So read it as a plausible benefit, not a proven one.

The practical point: the benefit on offer depends on problems being welcome in the room. A stand-up where people only report good news carries the daily cost without the payoff.

Which of these fixes has been tested?

None of the fixes in this guide has been tested in a controlled trial: each rests on qualitative studies and surveys of software teams, and the few comparative studies looked at whether to hold stand-ups at all and whether to stand, not at how to run them.

Limited evidence is not the same as bad advice: these fixes come from what worked for real teams, not from a head-to-head test. So run each as your own small trial: change one thing, keep it for a few weeks, and check whether the meeting got shorter and whether anyone’s plan changed.

The bottom line

A daily stand-up earns its 15 minutes when it is about today, not yesterday: each person says what they will do and what is in the way, teammates answer each other, and anything longer moves to a smaller conversation afterwards. If your stand-up has become a status report to one person, change the format before you cut the time, and if nobody’s plan ever changes because of it, meet less often.