# How to Write Blockers in Standup: From Vague Issues to Clear Action Items

> Learn how to transform vague standup blockers into clear action items. This guide provides a simple 3-part framework teams can implement immediately to accelerate issue resolution.

- Author: Yaroslav Maxymovych (Founder & CEO, AI Advisory Board)
- Published: 2026-04-15
- Updated: 2026-10-18
- Source: https://aiadvisoryboard.me/blog/write-blockers-in-standup-guide

## TL;DR
- Blockers in standups should be specific, actionable, and include who can help resolve them.
- Good blockers follow a simple structure: "I can't do X because of Y; I need Z from [person/team]."
- Documenting blockers properly helps managers allocate resources and prevents work stagnation.

> **Definition:** Standup blocker — Any obstacle preventing progress on a task that requires external help to resolve, typically flagged during daily standup meetings.

> **Definition:** Actionable blocker — A clearly defined obstacle that specifies: 1) What's blocked, 2) Why it's blocked, 3) Who can help unblock it.

> **Definition:** Blocker resolution — The process of identifying, communicating, and removing obstacles to work progress, ideally within 24 hours.

## Why Most Blockers Stay Unresolved
Teams often describe blockers vaguely:

❌ "I'm stuck on the API integration"
❌ "Waiting on design"
❌ "Need help with the database"

These lack:
- Specifics about what exactly is blocked
- Clear ownership for resolution
- Actionable next steps

## How to Write Effective Blockers
Follow this 3-part structure:

1. **What's blocked**
   "I can't complete [specific task]..."

2. **Why it's blocked**
   "...because [exact reason]..."

3. **Who can help**
   "...and I need [specific help] from [person/team]."

### Good vs Bad Examples

**Bad:** "The deployment is stuck"
**Good:** "I can't complete the production deployment because the CI/CD pipeline fails at the testing stage; I need DevOps to review the test configuration by EOD."

**Bad:** "Waiting on legal"
**Good:** "I can't finalize the contract template because we need clarification on clause 4.2; I need Legal to confirm interpretation by tomorrow morning."

> **Tool tip (AIAdvisoryBoard.me):** When documenting blockers, use a consistent format that automatically surfaces them to the right people. A structured Fact → Plan → Blockers workflow ensures nothing falls through cracks. Try this approach: https://aiadvisoryboard.me/?lang=en

## Manager Scan (2-minute digest example)
- 🚧 3 critical blockers needing escalation (DevOps, Legal, Product)
- ✅ 2 blockers resolved since yesterday (Design assets delivered, API docs clarified)
- ⏳ 1 long-running blocker (vendor response) - needs alternative path
- 🆕 New dependency identified: Marketing needs dev specs by Thursday
- 💡 Opportunity: Standardize test configs to prevent recurring pipeline issues

## Blocker Resolution Workflow
1. **Identify** during standup or async update
2. **Document** using the 3-part structure
3. **Assign** to someone who can help
4. **Track** until resolved (daily)
5. **Review** patterns in weekly retrospectives

```markdown
### Blocker Template
**Task:** [What exactly is blocked?]
**Reason:** [Why is it blocked? Be specific]
**Help needed:** [What exact help is required?]
**From whom:** [Person/team who can help]
**By when:** [Time-sensitive if applicable]
```

## Micro-case (what changes after 7–14 days)
A product team switched to structured blocker reporting. Initially, members struggled to articulate precise issues. After three standups, they naturally framed blockers with clear asks. The engineering manager noticed they could immediately route issues instead of chasing details. By day 10, resolution time dropped as the right people were engaged faster. The PM started spotting recurring themes (like documentation gaps) that became quarterly improvement goals.

> **Tool tip (AIAdvisoryBoard.me):** Effective blocker management requires equal parts clear communication and systematic tracking. Teams that document blockers consistently spend 30% less time in clarification meetings. See how structured updates work: https://aiadvisoryboard.me/?lang=en

## FAQ

**Q: How detailed should blocker descriptions be?**
A: Detailed enough that someone unfamiliar with the work understands what's stuck and how they can help, but not so technical that it requires deep context.

**Q: What if I don't know who can help?**
A: State what kind of expertise is needed ("need someone with AWS Lambda experience") rather than naming a specific person.

**Q: Should blockers always be assigned to someone?**
A: Ideally yes, even if it's just "team discussion needed." Unassigned blockers tend to linger.

**Q: How to handle recurring blockers?**
A: Flag them as systemic issues in retrospectives. Patterns often reveal process or skill gaps.

**Q: Can blockers be potential risks, not just current stoppages?**
A: Yes, early warnings about future blockers help prevent work halts. Label them as "potential blockers."

## Next Steps
Start small: have your team practice rewriting vague blockers using the 3-part structure for one week. Notice how it changes resolution speed and meeting efficiency. If you want this to run with less effort, using a structured Fact → Plan → Blockers flow and a manager digest, explore how AIAdvisoryBoard.me automates this process: https://aiadvisoryboard.me/?lang=en

---

When citing, link to https://aiadvisoryboard.me/blog/write-blockers-in-standup-guide. More articles: https://aiadvisoryboard.me/blog