9:30 AM. Eight engineers join a call.
First person: Backend work completed yesterday; continuing today; no blockers. Second person: still on the same
The ticket from yesterday, it should be finished today; there are no blockers. Third person: In review on the PR from last week, waiting on it.
Feedback, no blockers. By the fifth person, half the team has mentally left. The meeting ends exactly at 9:45.
Fifteen minutes, eight people, zero decisions, zero problems surfaced, and nothing changed.
That standup cost the team nothing in obvious ways. No conflict. No wasted argument. Clean and efficient. And yet
it was completely useless — because a standup that produces no decisions and surfaces no problems is just a
calendar event that everyone has learned to endure.
Do the maths on it, and the numbers get uncomfortable fast. An 8-person team running a 15-minute standup every
A working day is spent 500 hours a year in that meeting. At an average engineer salary of $75,000, that is $18,000 a
year, on a meeting where the most common output is eight people saying "no blockers" in sequence. If the
A standup run of 30 minutes instead of 15 doubles to $36,000. Across 10 teams, you are looking at $360,000 a
year in salaries spent on a ceremony that most people have stopped believing in.
A 2026 Forrester report found 40% of small- and mid-size businesses report standup fatigue. Separate data puts
30% of teams calling their daily standup are actively wasteful. None of this is a case against having standups — it is a
case for understanding why they stop working and what to do about it.
What the Standup Was Actually Designed to Do
Most teams running broken standups are not ignoring the format — they are following it exactly. Three questions,
fifteen minutes, same time every day. The problem is not that they drifted from the design. The problem is that the
40% of SMBs report standup fatigue (Forrester 2026)
Design itself got misunderstood somewhere along the way, and the misunderstanding got baked into the calendar.
The standup was never supposed to be a status report. The three questions are 'What did I do?', 'What will I do, any
blockers — a scaffold for a coordination conversation, not a script for individual performance reviews. They
were meant to get the team looking at the sprint together, not reporting upward to a manager.
The Scrum Guide is clear on this: the standup belongs to the developers. Its purpose is to inspect progress toward
the sprint goal and adapt the daily plan. The keyword is 'adapt'. If nothing is being adapted — if the standup ends
every morning without anyone changing what they are doing or how they are helping each other, the meeting is
not fulfilling its purpose, regardless of how efficiently it ran.
A standup doing its job sounds like this: someone says they have been stuck on an API integration for two days
and were not sure it was worth raising. Someone else says they worked on the same service six months ago and
can help right after the call. Ninety seconds. One blocker unblocked. One ticket that was heading toward carryover
gets rescued on day four instead of being discovered on day twelve.
A standup not doing its job sounds like eight people taking turns reading ticket titles. Nobody learns anything.
Nobody changes anything. The meeting ends on time, and everyone goes back to exactly what they were doing
before it started.
The 5 Patterns That Kill a Standup
Most standup problems are consistent across teams of different sizes, industries, and seniority levels. Once you
can name them, they are surprisingly easy to spot in your own team.
Pattern 1: The Status Theatre
Every day: "No blockers." Every single day. Even during the sprint that ended with three carryovers, a scramble on
Day thirteen and a retrospective, where everyone agreed estimation had been wildly off.
The "no blockers" answer is not dishonesty — it is self-protection. In most teams, naming a blocker in a standup
It feels like announcing a personal failure. You slow the sprint down. You get questioned about why it took two days
to surface. So the blocker stays in your head, gets mentioned to a colleague in Slack at 4 pm, and quietly stalls a
ticket for three days before anyone notices. By the time it surfaces, it has already cost the sprint half a week.
Pattern 2: The Live Problem-Solving Session
One blocker comes up in standup. Two developers have different views on how to approach it. The conversation
starts. The other six people on the call become an audience. The standup turns into a design review that runs 40
minutes and solves one problem while seven people wait. The moment a standup moves from surfacing to solving,
The Scrum Master should call it "Let's take this offline — who needs to be in that conversation?" Two people stay.
Six people get 35 minutes back.
Pattern 3: The Zombie Standup
Three years ago someone set up the standup. It made sense at the time. Now half the people in the meeting joined
after that setup. Nobody quite remembers the reasoning. But nobody removes it either — removing it feels like a
statement. So it stays. Same format, same time, same questions, same answers that stopped containing useful
information eighteen months ago. A 2026 analysis found teams consistently running standups longer than 20
minutes have sprint completion rates up to 15% lower than teams keeping them at 8 to 10 minutes. The zombie
standup is not neutral — it is a recurring drag on the sprint.
Pattern 4: The Manager's Briefing
Watch where people look during standup. In teams where the format has drifted, most people look at the manager
or the tech lead when they speak — not at the rest of the team. When you are reporting to a peer, you say the true
version of where things are. When you are reporting to the person evaluating your performance, you say the most
competent-sounding version. These are different things. If the honest answer to "who is this standup for" is "so the
The manager knows what is "happening"—the standup has become a tool for upward visibility, not team coordination.
Pattern 5: No Connection to the Sprint Goal
Standup ends. Eight people updated their tickets. Nobody asked whether the sprint is on track. An engineer at a
FinTech firm described it: strategic alignment "comes from our initiative — if you wanted to understand how your
work connected to the sprint goal, you had to ask for it yourself. Most people didn't. They worked on their tickets
and found out at the sprint review whether the pieces fit together. This is the standup that produces the sprint where
Everyone completes their tasks, and the demo reveals that nothing works end-to-end.
Table 1 — The 5 Standup Patterns That Don't Work
What Actually Works — The Standup Formats High-Performing Teams Use
None of the fixes below require a new tool or a new framework. They require changing what the standup is for —
which is a decision, not a purchase.
Walk the Board, Not the Room
Person-by-person standup: eight people take turns. Seven people wait while one person speaks. Board-based
standup: the team pulls up the sprint board together, starts with whatever is closest to done, and works backwards.
Items that have not moved in two days get flagged immediately — not because someone volunteers the
information but because the board makes it visible.
When the conversation is about a ticket, anyone with relevant information speaks. The frontend developer
mentions UI completion, the backend developer connects it to the API status, the QA engineer flags a test
environment issue. All three things surface in 90 seconds because the ticket is the focal point, not anyone's
reputation.
Two Questions Instead of Three
The three standard questions have a structural problem: two are about the past. Teams that consistently run more
useful standups have swapped them for two forward-looking questions:
— Is this sprint on track to hit its goal?
— What needs attention today that is not getting it?
Both require collective thought rather than individual recollection. Neither can be answered with a clean one-liner.
"I don't know if we're on track" is the most useful thing a team can say in a standup – it opens the only
conversation the meeting actually needed to have.
Time-Box the Update, Not the Meeting
The 15-minute rule is a discipline about what deserves the group's attention out loud versus what belongs in Slack
or a ticket comment. An update that requires no decision and has no risk attached to it does not need to be said in
standup. What belongs in standup: anything that requires a decision from more than one person, anything at risk of
blocking shared progress, anything where the whole team needs to change how they are approaching the sprint.
That is it.
Create Safety for Real Blockers
If developers in your standup never report genuine blockers, the problem is not that they do not have any. Google's
Project Aristotle research found that psychological safety is the single most important factor in how well teams
perform. In standup terms, this means the Scrum Master explicitly welcomes obstacles – not "any blockers?" as a
checkbox, but "what is making your work harder right now?" When a developer surfaces a problem, and the
If the response is "Thanks for saying that — who can help?" rather than silence, the norm starts to shift. Teams that build
This finds their standups dramatically more useful within two or three sprints.
Table 2 — Standup Formats: What Most Teams Do vs What Works
What About Async Standups?
The async standup — where team members post written updates in Slack rather than joining a live call — has
become more common in 2026, particularly in distributed and remote teams. For some teams, it is a genuine
improvement. For others, it just moves the dysfunction to a different medium.
The case for async: it eliminates time zone problems and removes the context-switching cost of joining and leaving a
call, and gives each person flexibility. A 2026 analysis noted that the meeting cost of a daily standup includes not
just the 15 minutes of the call but the 20 minutes of ramp-up time lost before and after — the cognitive cost of
stopping deep work to join a meeting and trying to resume it. Async removes that entirely.
The case against: written updates are easier to sanitise. The temptation to write a polished async update that omits
The real difficulty of the day is even higher than the standup pressure to say "no blockers". Without a live facilitator
who can ask a follow-up question when something sounds off, async standups can produce the cleanest-sounding
Updates from the most struggling team.
The teams that get the most from async standups combine it with a brief live sync two or three times a week — not
a full standup, just a check on whether anything in the async updates needs a conversation. The daily written
update provides visibility. The occasional live moment provides the human layer that text cannot fully replace.
The Cost of Getting This Wrong at Scale
A single team running a broken standup loses between $18,000 and $36,000 in direct meeting costs every year.
That is before the opportunity cost — the deep work that did not happen because eight engineers interrupted their
morning for a meeting that produced nothing.
At ten teams, that is between $180,000 and $360,000 a year. A single engineer can lose between 130 and 390
hours per year to a standup that is not working — roughly 0.4 to 1.1 full-time work years. That is not the cost of a
broken process. That is the cost of a broken process that nobody has decided to fix.
The barrier to fixing standups is almost never technical. Most teams know their standup is not working. They talk
about it in retrospectives. They agree it could be better. Then the next Monday arrives and the same calendar
The invite goes out, and the same format runs again. The fix requires one decision: someone decides the standup is
worth redesigning rather than just enduring. Walk the board, anchor to the sprint goal, create safety for real
blockers, and time-box ruthlessly. None of that requires a new tool. It requires a norm change. And norm changes are
free.
How Spryn Helps With This
Spryn (spryn.io) was built around one observation: most of the information that should surface in a standup is
already in the sprint board — but in most tools, nobody looks at the board before the standup. They describe their
tickets from memory, which is where half the useful information gets left out.
When your team opens a sprint in Spryn before standup, what needs attention is already visible. Tickets that have
Those not moved in two days are flagged. The scope that has grown since the sprint started is visible. The sprint goal and its
Current statuses are on the same screen as the individual tasks. Nobody has to reconstruct the picture from verbal
updates — the picture is already there, and the standup becomes a conversation about it rather than a description
of it.
The AI standup feature takes this further. Before the meeting starts, Spryn generates a summary of who is moving.
who is blocked, and what is at risk — based on actual sprint data, not self-reported updates. The standup starts
with a shared view of reality rather than a round of individual recollections. For teams where the standup has
become a status report nobody listens to, that is the shift that makes it worth having again.
Questions Teams Ask About Fixing Their Standup
1.Our standup always runs long. How do we fix it without cutting people off?
The length problem is almost always a facilitation problem, not a people problem. When something needs more
than two minutes, name it: "This needs a deeper conversation — let's take it offline. Who needs to be in it?" That
one phrase, used consistently, trains the team over two or three sprints that the standup is for surfacing, not
solving.
2.Should we cancel standups for remote or async teams?
It depends on what is breaking down. If the problem is time zones, async standup with a few live check-ins per
week often works better. If the problem is quality of information, switching to async usually makes it worse.
written updates are easier to sanitise than live ones. Before cancelling, try changing the format for two weeks and
measuring whether the quality of information improves.
3.Our team says "no blockers" every day, but tickets are consistently stalling. What is going on?
The standup has become a social performance rather than a coordination tool. The social cost of surfacing a
blocker — being questioned, looking slow, being responsible for the sprint missing — is higher than the cost of
staying quiet. The fix is a norm change: the Scrum Master has to explicitly model that surfacing problems is valued.
The first time a developer says, "I am stuck on this", and the response is "thank you — who can help?" rather than
silence, the norm starts to shift.
4.How many times a week should teams actually have a standup?
There is no universal answer. Some teams run effective daily standups. Others find that three times a week gives
enough coordination without the daily interruption cost. The right frequency is the one where the meeting
consistently produces a decision or an action — if it is producing neither, reduce the frequency before changing the
format.