A blocker is a signal, not just an annoyance
A blocker is the system telling you that work is creating drag, delay, or avoidable risk. The value comes from making it visible, named, and attached to the card, instead of leaving it as private frustration in a chat thread that the board never reflects.
Two kinds of blocker
| Kind | What it means | Where to act |
|---|---|---|
| Person blocker | Work is waiting on a specific person, "waiting on Bob", "Alice is out" | Coordinate directly; reassign or escalate if it lingers |
| Card blocker | Another card must finish first, a real dependency | Track the upstream card; the blocked card clears when it resolves |
They are different problems. A person blocker is about availability and ownership; a card blocker is about sequencing. Naming which one you have decides what you do next.
Internal vs external blockers
Scope answers a different question than status: who, and where, must unblock this? ScrumDo sets it from where the two cards live and lets you override it.
| Scope | Meaning | How to treat it |
|---|---|---|
| Internal | Both sides live in the same room or team; a room owner can usually resolve it | Coordinate with the owner. Information, not a fire drill. |
| External | It depends on something outside this team, a vendor, a customer, or an upstream team | Escalate, and record the "who": vendor, customer escalation, upstream team. Treated as blocking. |
Keeping the two distinct stops every blocker from being treated as an emergency, and stops a real external dependency from hiding as a quiet internal note.
Name the cause
A blocker without a cause is hard to act on and impossible to learn from. ScrumDo offers a short, shared list of causes so patterns become visible across the board:
- Waiting on a decision, a customer, a vendor, or another internal team
- A technical issue
- A dependency on another card
- A capacity constraint
- Scope or requirements not yet settled
- Approval or compliance
- An external event or market change
Because the causes are a shared set, repeated patterns, "a third of our blockers are waiting on one vendor", become a system signal you act on in planning, not a string of one-off complaints.
Blockers and dependencies move together
When a blocker is really a dependency, the blocked card reflects the upstream card’s state and clears when that upstream work is done. If schedules shift, dependent work can shift with it, circular dependencies are caught rather than silently tolerated, and the history of who changed what stays on the record.
Escalate by class of service
A blocker on a high class-of-service card is more expensive than one on routine work. A blocked Expedite or Fixed delivery date card should be escalated; a blocked Standard card can often wait its turn. This is where blockers meet Cost of Delay, the cost of a blocker is the cost of delay it is causing.
Key terms
- Person blocker
- Work waiting on a specific person’s availability or decision.
- Card blocker
- Another card must finish first, a tracked dependency.
- Internal blocker
- Can be resolved inside the same team or room; information, not escalation.
- External blocker
- Depends on a vendor, customer, or upstream team and needs escalation, with the "who" recorded.
- Show-stopper
- A blocker serious enough to stop the work entirely until it is resolved.