One ticket is blocking five others. Here's how to find it
Every board has a ticket quietly holding up several others. Counting blockers doesn't find it — measuring what's stuck behind them does.
Blocked work is the most expensive thing on your board and the easiest to miss. A blocked ticket looks calm: it isn't moving, nobody's complaining, it doesn't appear in anyone's update. Meanwhile three other tickets can't start.
Why counting blockers doesn't help
Plenty of tools will show you "8 blocked items". That number is nearly useless, because blockers aren't equal. One might be a nice-to-have waiting on a design tweak. Another might be an API contract that four people need before they can write a line of code.
The useful question isn't how many things are blocked — it's what is each blocker costing.
Rank by what's stuck behind it
Follow the dependency chain from each blocking ticket and count everything downstream, including transitive dependencies. That gives you a cost per blocker, and the ordering is usually a surprise: the item at the top is rarely the one people have been talking about.
VectorKan's blocker radar does exactly this. For each blocker it shows:
- How much work is stuck behind it, following the chain rather than just direct links.
- How long it's been waiting — because a two-day block and a three-week block need different conversations.
- Who owns it, so unblocking has a name attached rather than being everyone's problem.
The other radar: workload
The same view flags a related problem — the teammate carrying roughly twice everyone else's load. That person is usually the team's most capable engineer, which is exactly why work keeps landing on them, and exactly why they become a bottleneck nobody names.
Seeing it as a number rather than a vibe makes it possible to fix. Rebalancing is an easy conversation when the board shows the imbalance; it's an awkward one when it's a hunch.
Building the habit
- Check the top blocker before standup, not during. Walk in already knowing what to ask about.
- Give every blocker an owner — the person who will chase it, not necessarily the person who will fix it.
- Escalate on age, not noise. The loudest blocker isn't the oldest, and the oldest is usually the one quietly costing you a week.
- Link tickets properly. The radar is only as good as your links; "blocks" and "relates to" take two seconds to set and pay for themselves the first time.
What changes
The realistic result isn't fewer blockers — you'll always have some. It's that they get cleared in the right order, and that "why did this take three weeks?" stops being a question answered after the fact.
Frequently asked questions
How do you identify the most important blocker?
Rank blockers by how much work is stuck behind them, following the dependency chain rather than counting direct links. The blocker with the largest downstream cost is the one to clear first, and it's often not the one being discussed most.
What is a blocker radar?
A view that ranks blocking tickets by their downstream impact, shows how long each has been waiting, and names the owner. VectorKan includes one, alongside a workload view that flags teammates carrying far more than their share.
How do you stop work getting blocked so often?
Link dependencies as you create tickets, give every blocker a named owner responsible for chasing it, and review the oldest blockers rather than the loudest ones.
How can I tell if one person is overloaded?
Compare assigned in-progress work across the team. VectorKan's workload radar flags anyone carrying roughly twice the team average, which turns an awkward hunch into a straightforward rebalancing conversation.