Standup blockers: how to surface them early and actually resolve them
“No blockers” is the most common answer in a standup and often the most expensive one. The blocker usually exists; it just has not been said yet. It shows up three days later as a missed deadline, when it is no longer a ten-minute conversation.
The 2025 research on standups explains why this happens. In a survey of 318 employees in agile teams and an intervention with student teams, Rietze and Zacher found that standups work through psychological safety, the belief that it is safe to take interpersonal risks within the team. Admitting you are stuck is exactly that kind of risk. This guide covers why blockers stay hidden, how to surface them earlier and how to make sure they get resolved after the meeting ends.
Why blockers stay hidden
A blocker is anything that stops or slows planned work and that the person cannot remove alone: a missing decision, a dependency on another team, access, unclear requirements or a technical problem outside their control.
Three patterns keep them quiet:
- The standup feels like a report to the boss. In a study of 12 software teams, “status reporting to the manager” was one of the main reasons people disliked standups. When the meeting is an evaluation, saying “I’m stuck” feels like admitting failure.
- The question is binary. “Any blockers?” invites “no.” Most problems are not full blocks yet; they are risks, slowdowns or open questions.
- Nothing happens when you say it. If a raised blocker gets a nod and no owner, people stop raising them.
The Rietze and Zacher findings suggest the first pattern is the one to fix first. When the standup builds safety, it is also linked to higher work satisfaction and team performance perceptions, which makes speaking up part of how the team works, not an exception.
How to surface blockers earlier
Change the question, give the answer a place, and lower the bar for what counts.
- Ask about risk, not only blocks. “Is anything slowing you down or at risk of slipping this week?” gets earlier, more honest answers than “any blockers?”
- Ask who you need. “Who do you need to talk to today?” turns hidden dependencies into a name.
- Separate the blocker field. In written standups, a dedicated blocker answer is easier to scan and harder to bury in a long update.
- Rate confidence. A quick “how confident are you that we hit the sprint goal, 1 to 5?” exposes problems people have not framed as blockers yet.
- Let the facilitator rotate. When the lead is not running the meeting, it reads less like an evaluation.
How to resolve blockers after the standup
Surfacing a blocker is half the job. The standup should end with each blocker having an owner and a next step.
| Blocker type | Example | Who owns it | Typical next step |
|---|---|---|---|
| Decision | “I need to know which pricing to show” | The decision maker | Answer within the day or set a deadline |
| Dependency | “Waiting on the API from Platform” | The person blocked, plus the other team’s lead | Direct message or short call today |
| Access or tools | “No access to the production logs” | Team lead or IT | Request filed before noon |
| Unclear scope | “The ticket can be read two ways” | Product owner | Ten-minute clarification after standup |
| Technical | “Tests fail only in CI” | A teammate with context | Pairing session today |
Two habits make this stick. First, the facilitator reads back the list of blockers and owners before closing. Second, the next standup starts with yesterday’s blockers: closed, still open, or escalated. For how this fits into the full meeting, see how long a daily standup should be.
Psychological safety is not the whole story
There is a well-supported counterpoint. In a study of 217 practitioners in 38 software teams across five Swedish organizations, Per Lenberg and Robert Feldt found that norm clarity, how clearly the team understands what is expected, predicted team performance and job satisfaction more strongly than psychological safety: 30% and 71% stronger, respectively. The study is cross-sectional and relies on self-assessed performance, but the implication is practical.
Safety helps people say “I’m stuck.” Clear norms decide what happens next. A team can feel safe and still let blockers sit for days if nobody knows who owns a dependency, how fast a decision should come back or when to escalate. In our experience the fix is to make those rules explicit: a written definition of a blocker, an expected response time and an escalation path.
How we handle blockers at Dailybot
We treat blockers as the most important output of the standup, not a closing question. In Dailybot, blockers are their own answer in the check-in, they are flagged as soon as someone reports them, and the compiled report in Slack, Microsoft Teams, Google Chat or Discord puts them at the top so a lead can act the same morning. Because updates are written, the history shows how long a blocker stayed open.
If your team spans time zones, a written blocker reaches the right person hours earlier than waiting for the next shared call. See standups across time zones and what a daily standup meeting is for the full format.
Start tracking blockers in your standup for free
Frequently asked questions
What is a blocker in a standup? Anything that stops or slows planned work and that the person cannot remove on their own, such as a missing decision, a dependency or an access problem.
What is the difference between a blocker and an impediment? In practice they mean the same thing. Scrum uses “impediment”; most teams say “blocker.”
What should I say when I have no blockers? Name your biggest risk instead. “No blockers, but the review from Design could slip to Thursday” is more useful than “none.”
Who is responsible for removing blockers? Each blocker needs one named owner. In Scrum, the Scrum Master helps remove impediments, but the owner is whoever can actually resolve it.
How do you track blockers in an async standup? Use a dedicated blocker question, highlight blockers in the compiled report and review open ones at the start of the next standup.
