The standup starts normally. One developer says the deploy is blocked. Someone asks a clarifying question. A second person has context from yesterday. Five minutes later, the team is debugging in public while three people with no stake in the blocker are waiting for their turn.
The blocker needed attention. The standup was the wrong room for solving it.
A useful standup identifies the blocker, decides who needs the follow-up, and protects the rest of the team's working time. If the blocker needs more than two clarifying questions, name the owner, helper, and follow-up time, then move on.
Why "take it offline" feels unsatisfying
"Take it offline" is common standup advice, but it often sounds like the facilitator is pushing away the only useful part of the meeting. The blocked person hears: thanks for raising the issue, now disappear with it.
Long standups keep happening because the team lead does not want to dismiss a real blocker. The senior engineer wants to be helpful. The person who raised the blocker wants proof that someone will stay with the problem. So the group keeps talking.
Scrum Alliance describes the Daily Scrum as a maximum 15-minute event for transparency, roadblocks, and focus: https://resources.scrumalliance.org/Article/the-daily-scrum. Sense and Respond makes the practical failure clear: problem-solving inside the standup is a common cause of length creep, and the facilitator's job is to record the impediment and commit to the relevant follow-up: https://www.senseandrespond.co/blog/fixing-broken-standups.
Moving a blocker out of the standup works only when the handoff is concrete.
Use a two-question threshold
Give the blocker enough room to become understandable. Do not give it the whole standup.
Use this threshold:
- Question 1: What is blocked?
- Question 2: Who or what is needed to unblock it?
If the team needs a third question, the blocker has crossed from standup signal into follow-up work.
Example:
A backend developer says the staging deploy is blocked because the migration fails. The release lead asks which service owns the migration. Another engineer asks whether the error is repeatable locally. At that point, the standup has enough information: deploy is blocked, the migration owner and release lead need to talk, and the rest of the team does not need to watch the debug path.
The next move is a handoff with names and time:
- Blocker: staging deploy migration failure.
- Owner: the backend developer who raised it.
- Helper: the release lead.
- Follow-up: stay on the Meet for 10 minutes after standup.
- Update: post the result in the release channel by noon.
Now the blocked person has help, and everyone else gets their morning back.
Reserve the last 3 minutes for handoff
For a 15-minute standup, plan to stop normal updates at minute 12. The final 3 minutes are for blocker routing:
- Which blocker needs a smaller follow-up?
- Who is staying?
- When will the team hear the result?
- Does any blocker threaten today's delivery goal?
A Reddit remote-work poster described a familiar version of the failure: a 10 to 15 minute standup dragging past 30 when a small blocker becomes a 10-minute discussion while half the team waits: https://www.reddit.com/r/remotework/comments/1r02oos/are_daily_standups_actually_necessary_or_is_there/. In another agile discussion, practitioners described hiding blockers when raising one leads to public problem-solving or escalation: https://www.reddit.com/r/agile/comments/1si0jsb/why_does_everyone_always_say_they_have_no/.
Those two complaints point to the same fix. The standup needs to make blocker reporting safer and shorter at the same time. A reliable handoff does both.
The blocker handoff card
Copy this into your standup notes or chat:
Blocker:
Impact today:
Owner:
Helper:
Follow-up time:
Where the update will be posted:
Escalation needed:
The "impact today" field prevents the team from treating every frustration as equally urgent. The "where the update will be posted" field prevents the parking lot from becoming a private side quest.
Use the card only for blockers that need action. If someone is giving a long status update, use the sprint goal or board to bring them back. A Workplace Stack Exchange question about scrum meetings described one person taking at least five minutes for a detailed update while others took about twenty seconds: https://workplace.stackexchange.com/questions/50729/how-to-handle-a-scrum-member-speaking-for-too-long. That is a different problem. Long status needs format change. Real blockers need handoff.
Set a recurring reminder inside Google Meet
If your standup happens in Google Meet, Minute Minder (https://minuteminder.io) can make the cutoff visible without asking the facilitator to watch the clock. It starts from the Google Calendar event, shows a timer inside Google Meet, and can trigger custom reminders.
For a 15-minute daily standup:
- Minute 10: "5 min left: blockers only."
- Minute 12: "3 min left: owner, helper, follow-up time."
- Minute 15: "Overtime: end standup or declare a separate debug call."
Turn on Minute Minder's optional sound for the minute 12 reminder if the team tends to miss visual cues. Minute Minder gives the facilitator the right cue at the moment the meeting usually changes shape. The team still diagnoses the blocker and writes any notes it needs.
When the standup should end early
Sometimes a blocker is serious enough to become the meeting. A production incident, release-stopping failure, or customer-impacting outage may need everyone who is present.
Do not let that happen silently. End the standup and name the new meeting: incident triage, release fix, customer-impact review. Let people who are not needed leave. Invite anyone missing who should be there.
This declaration protects both meetings. The standup did its job by surfacing the blocker. The next call can solve it with the right people.
Long standups often come from good intent. People want to help. The fix is to make help smaller, clearer, and closer to the people who can use it. A blocker that leaves standup with owner, helper, time, and update path is more likely to be solved than a blocker debugged halfway while the rest of the team waits.
Sources
- Scrum Alliance, "What Is the Daily Scrum?": https://resources.scrumalliance.org/Article/the-daily-scrum
- Sense and Respond, "Fixing Broken Standups": https://www.senseandrespond.co/blog/fixing-broken-standups
- Stray, Moe, and Sjoberg, "Daily Stand-Up Meetings: Start Breaking the Rules": https://arxiv.org/abs/1808.07650
- Remote work discussion on long standups: https://www.reddit.com/r/remotework/comments/1r02oos/are_daily_standups_actually_necessary_or_is_there/
FAQ
How long should a daily standup be?
Scrum guidance frames the Daily Scrum as a maximum 15-minute event. For remote teams, a useful working rule is to stop normal updates around minute 12 and reserve the last 3 minutes for blocker handoff.
Should blockers be discussed in standup?
Blockers should be surfaced in standup. Detailed debugging should move to the smaller group that can solve it, with owner, helper, follow-up time, and update path named before the standup moves on.
What should I do when one person talks too long in standup?
Separate long status from blocker discussion. Long status needs a format reset around the sprint goal or board. A real blocker needs a handoff card so the person gets help without consuming the whole meeting.
Should a daily standup have a hard stop?
For normal updates, yes. Stop updates around minute 12 of a 15-minute standup and use the rest for blocker handoff. If a blocker is serious enough to need everyone, end the standup and start a separate call.
Top comments (0)