5 questions on understanding blocker vocabulary in standup dialogues — the precise meaning of "blocked", "at risk", "dependency", and ownership language.
Standup blocker vocabulary — key distinctions
blocked — work has stopped NOW; an external obstacle prevents progress
at risk — a potential blocker; work can continue but may stop
dependency — reliance on another person's or team's output
"take this offline" — discuss outside the standup, not in this meeting
"who owns the resolution?" — who is accountable for removing the block
0 / 5 completed
1 / 5
In a standup, Alex says: "I'm blocked waiting on the API spec." What does blocked mean precisely in this context?
Blocked is one of the three core standup signals (Yesterday / Today / Blockers). It means an external dependency or obstacle is preventing progress — the person cannot move forward until the block is removed.
Key vocabulary:
"I'm blocked" = external obstacle stopping progress right now
"Blocked waiting on [person/thing]" = the blocker is a dependency — common pattern
"I'm blocked on the API spec" = the spec is missing or incomplete, and work cannot continue without it
Distinction: "Blocked" is stronger than "at risk" — it means work has already stopped, not just that it might stop. In scrum, it is the Scrum Master's job to remove blocks as quickly as possible.
2 / 5
During a standup, a developer says: "The third-party integration is at risk — the vendor hasn't confirmed the SLA." Is "at risk" the same as "blocked"?
"At risk" and "blocked" are different severity levels:
Blocked = work has stopped NOW. Cannot continue without intervention.
At risk = a potential blocker exists. Work can continue for now, but may stop if the risk materialises.
Examples:
"I'm blocked waiting on design approval" — stopped now
"The delivery is at risk — we're still waiting on the vendor's confirmation" — may slip if not resolved
Why it matters: In standups, the Scrum Master or team lead should treat "at risk" items as early warnings and act proactively, rather than waiting until they become full blocks. Communicating "at risk" is a sign of professional foresight.
3 / 5
The Scrum Master asks: "Who owns the resolution?" What are they asking for?
"Who owns the resolution?" is ownership language — the Scrum Master is asking: who is accountable for making this blocker go away?
Standup ownership vocabulary:
"own the resolution" = be responsible for resolving it — not just aware of it
"take ownership of" = accept accountability for an outcome
"who is on point for this?" = same meaning, more informal
In practice: A good answer is: "I'll own it — I'll follow up with the vendor by end of day."
Scrum Masters ask this to ensure every blocker has a named person driving resolution. A blocker without an owner is a blocker that will linger.
4 / 5
A team member says something that requires a longer discussion. The Scrum Master responds: "Can we take this offline?" What does this phrase mean in a standup?
"Take this offline" is a very common meeting phrase meaning: let's discuss this in a separate conversation, not in this meeting.
Why it's used in standups: Standups are timeboxed (typically 15 minutes). Deep discussions about a single blocker can derail the format. "Offline" here does not mean off the internet — it means outside of this meeting.
Common variants:
"Let's take this offline." = discuss after the call
"We can park that for now." = put it aside, return to it later
"Can we pick this up in a separate thread / call?" = same idea
In a standup, the standard pattern is: surface the blocker quickly → assign ownership → take the detailed discussion offline.
5 / 5
A developer says: "No blockers — but I have a dependency on QA finishing the regression before I can release." Is there a risk in this update?
A dependency is a potential blocker — even when the developer says "no blockers" today, naming a dependency is a soft warning signal.
Key insight: In standup language, "I have a dependency on X" means my progress is connected to someone else's output. If that output is late, I am blocked.
Good standup communication: Flagging dependencies proactively (even when not yet blocking) allows the Scrum Master and team to monitor risks early. The developer here is communicating well — they said "no blockers" (accurately: work is not stopped today) and flagged the dependency.
Vocabulary:
dependency = reliance on another team's or person's output
at risk = potential future block (the release is at risk here)