Choose the most effective phrasing for communicating blockers, dependencies, and escalations in 5 real scenarios.
The complete blocker statement has 4 parts
What: the task blocked — "I'm blocked on the API integration task"
Why: the cause — "waiting on the API contract from the Platform team"
When: expected resolution — "ETA: end of today"
Action: what you'll do — "I'll follow up with them directly after this call"
0 / 5 completed
1 / 5
You are blocked waiting for a security review before you can deploy to production. The security team hasn't responded to your request from two days ago. How do you communicate this in the standup?
Why B is the model answer: specificity + ownership + impact
A great blocker update has four parts:
Task blocked: "blocked on the production deployment"
Cause: "submitted a security review request 2 days ago — no response"
Action you're taking: "I'll follow up with their team lead directly after this standup"
Impact: "could delay the sprint goal"
Why the others fail:
A: Accurate but has no timeline, no action, no impact
C: Blaming the security team is unprofessional in a standup
D: Vague — nobody knows what you're waiting for or when it will be resolved
Key escalation vocabulary:
"I escalated this to [person] — awaiting response"
"This is now a sprint risk — the blocker is pending [X]"
"I need [manager] to unblock this if it doesn't resolve by [time]"
2 / 5
A colleague asks in Slack: "What's your current status on the payment integration?" You have been blocked waiting for a vendor API key for 3 days and it is now blocking the team's sprint goal. Which response is most professional and useful?
Why B is excellent: proactive, transparent, actionable
This response demonstrates professional ownership of a dependency:
Clear status: "blocked on vendor API key"
Timeline: "requested 3 days ago, two follow-ups sent"
Escalation path: "raising as sprint risk to [PM]"
Mitigation proposal: "consider moving the story to next sprint" — proactively surfacing options
Sprint risk vocabulary:
"This is now a sprint risk"
"We may need to descope this if [blocker] isn't resolved by [time]"
"I'm flagging this as a dependency risk for the sprint goal"
Why the others fail:
A: Defensive — "not my fault" is irrelevant in a professional context
C: Accurate but passive — no follow-up, no impact, no timeline
D: Completely uninformative
3 / 5
Your task depends on a teammate finishing their PR review, but they've been in back-to-back meetings all day. You need the review by end of day to meet the sprint deadline. Which approach is most effective?
Why B is correct: clear dependency + asking for solutions
This response shows good professional judgment:
Identifies the dependency precisely: "[colleague]'s PR review"
States the deadline and impact: "need it by EOD to ship on time"
Proposes a solution: "can someone else pick it up?"
Invites the team: makes the blocker a shared problem, not a complaint
Useful phrases for dependency escalation:
"I need [X] from [person/team] to proceed — is there someone who can unblock this?"
"If [person] isn't available, could [alternative person] cover this?"
"I want to flag this dependency before it becomes a blocker for the sprint goal."
C is wrong: merging without review bypasses the team's quality process — even under deadline pressure, this should be a team decision, not a unilateral one.
4 / 5
Your manager asks: "Why haven't you started on the new feature yet?" You've been waiting for the design mockups from the UX team for a week, but you didn't raise it in standups. How do you explain this professionally?
Why B is the professional response: honesty + accountability + next steps
This response demonstrates maturity:
Explains the dependency clearly: waiting for approved UX mockups
Acknowledges the mistake: "I should have raised this dependency earlier" — owns the communication failure without being defensive
States current status and ETA: "expected by [date]"
Commits to an action: "I'll follow up today and flag any delay immediately"
The key skill here: admitting that you didn't escalate a blocker is hard but necessary. Professionals flag issues early. When you don't:
The team can't help
Deadlines are missed without warning
Trust erodes
Better standup practice going forward: raise dependencies before they become blockers — "I'm waiting on UX designs — expected by [date]. If they don't arrive, I'll flag it."
5 / 5
During a standup, you realise your blocker is actually a decision that only the Product Owner can make — you need a priority call between two competing tasks. How do you surface this correctly?
Why B is the model answer: frames the decision clearly for the decision-maker
When you need a decision unblocked, the professional approach is to:
Name the decision clearly: priority between two specific tasks
Give context for each option: payment module blocks sprint demo / compliance task has a regulatory deadline
State the constraint: "I can't progress on both"
Name who needs to decide: "[PO]'s input"
Request the action: "I need a priority call"
This does NOT mean asking others to do your job — you've clearly identified the issue and the decision-maker. You're escalating a priority conflict, not passing responsibility.
Useful phrases for escalating decisions:
"I need a decision from [person] on [X] vs. [Y] — both are time-sensitive."
"Can we take 5 minutes after the standup to align on priority?"
"I can't proceed without a call on [specific decision] — who's the right person to make this?"