Definition
Blocker
A blocker is anything that prevents an issue from progressing until it is resolved — a dependency on unfinished work, a pending decision, a missing access, or an external delay. Marking work as blocked makes hidden stalls visible so the team can clear them deliberately, rather than letting issues quietly age in progress.
Key takeaways
- A blocker is anything that prevents an issue from progressing until it is resolved — a dependency on unfinished work, a pending decision, a missing access, or an external delay. Marking work as blocked makes hidden stalls visible so the team can clear them deliberately, rather than letting issues quietly age in progress.
- Blocked work is the silent killer of flow.
- Planoda lets you mark issues blocked and link blocking dependencies, surfacing them prominently so stalled work is escalated instead of silently aging.
Blocked work is the silent killer of flow. An issue sits in 'in progress,' but no one is actually working it because something out of the assignee's control is in the way: a needed API isn't ready, a design decision is unmade, a credential is missing, a vendor hasn't replied. Untracked, it looks active while it stalls, inflating cycle time and hiding the real bottleneck.
Naming the blocker is the whole point. Marking an issue blocked — ideally with what it is waiting on — converts an invisible stall into a visible signal the team can act on. Blockers belong at the top of standup and on the board in a color you cannot miss, because clearing them is almost always higher-leverage than starting new work.
Blockers come in two flavors: dependencies on other tracked issues, which a tool can model as explicit links, and external waits, which need an owner and a follow-up. Either way, the goal is to make blocked time short and accountable rather than letting items languish.
Planoda lets you mark issues blocked and link blocking dependencies, surfacing them prominently so stalled work is escalated instead of silently aging.
Related terms
- WIP LimitA WIP (work-in-progress) limit is a cap on how many items may be active in a given workflow stage at once. By forcing a team to finish work before starting more, WIP limits expose bottlenecks, reduce context-switching, and shorten cycle time. They are the core mechanism that makes Kanban flow rather than pile up.
- Cycle TimeCycle time is how long an issue takes from the moment work actively starts on it to the moment it is done. Measured in hours or days, it captures the team's hands-on flow efficiency. Shorter, more consistent cycle times mean a more predictable system — the core flow metric Kanban teams optimize.
- StandupA standup is a brief, regular team sync — often daily and time-boxed to fifteen minutes — where members share progress, plans, and blockers. Kept short by design (traditionally held standing up), it aligns the team and surfaces obstacles early without becoming a status meeting. The focus is on flow and blockers, not detailed reporting.
- TriageTriage is the process of reviewing newly reported issues and deciding what happens to each — accept and prioritize, request more detail, route to a team, or close. Borrowed from emergency medicine, it keeps the incoming flow of bugs and requests from overwhelming a team by quickly sorting signal from noise at the front door.