Tracking Blockers So They Don't Silently Kill Your Sprint
Tracking Blockers So They Don't Silently Kill Your Sprint
TLDR: Untracked blockers are the leading cause of missed sprint goals because teams often do not realize work has stalled until it is too late to recover.
A blocker does not announce itself with fanfare. It shows up quietly as a card that stops moving on your board. The developer waiting on an API key from a third-party vendor. The designer who cannot finalize a layout because the copy has not been approved. The tester who is blocked because the staging environment is down. Each of these blockers is small in isolation but devastating when left unresolved for days.
Why Blockers Go Unnoticed
The most dangerous blockers are the ones that look like normal work in progress. A card in the In Progress column does not tell you whether someone is actively working on it or staring at it helplessly because they need something they do not have. Without explicit blocker tracking, the only way to know is to ask each person individually, and that does not scale.
Teams without blocker tracking often discover stalled work during sprint review, when the card still sits in progress and the sprint goal is missed. By then, the damage is done. The sprint is incomplete, the timeline has slipped, and the team's confidence in their process is shaken.
Making Blockers Visible
The first step is creating a system where blockers cannot hide. In LocalPM, you can use labels, a dedicated Blocked column, or both.
The Blocked column approach. Add a column called Blocked to your board, positioned between In Progress and In Review. When a card becomes blocked, the owner moves it to this column immediately. The visual impact is powerful. A Blocked column with three cards in it is an urgent signal that demands attention during the daily standup.
The label approach. If you prefer not to add another column, use a red "Blocked" label on cards that are stuck. This keeps the card in its workflow position but makes its status visually distinct. The advantage is that you can see where in the workflow blockers tend to cluster.
The combination approach. Use both. Move blocked cards to the Blocked column and tag them with a label indicating the type of blocker: external dependency, waiting on decision, environment issue, or missing information. This gives you both immediate visibility and data for identifying patterns over time.
The Blocker Resolution Protocol
Visibility is only half the solution. You also need a protocol for resolving blockers quickly.
Ownership. Every blocker needs an owner who is responsible for resolution. This is often not the person who is blocked. If a developer is waiting on design assets, the blocker owner might be the design lead or the project manager who can escalate the request.
Escalation timeline. Define how long a blocker can exist before it escalates. A reasonable default is twenty-four hours. If a blocker is not resolved within one business day, it escalates to the team lead or project manager. If it persists for forty-eight hours, it reaches the stakeholder who can authorize a workaround or reprioritize.
Daily review. During the standup, review every item in the Blocked column or with a blocked label. Ask two questions: "What needs to happen to unblock this?" and "Who is responsible for making that happen?" Do not move on until both questions have clear answers.
Patterns That Reveal Systemic Issues
After a few sprints, review your blocker history. Patterns will emerge that point to systemic problems rather than one-off incidents.
If blockers frequently involve external dependencies, your planning process is not accounting for lead times from other teams or vendors. Build buffer time into stories that depend on external inputs.
If blockers cluster around a specific team member, that person may be a bottleneck. They might need support, the workload might need redistribution, or the team might need cross-training to reduce single points of failure.
If blockers often involve environment or tooling issues, your infrastructure needs investment. Recurring technical blockers are a sign that the team is fighting their tools instead of using them.
Prevention Is Better Than Tracking
The best blocker is one that never occurs. During sprint planning, ask for each selected story: "What could block this?" If the answer involves an external dependency, confirm that the dependency will be available before the story starts. If the answer involves a decision that has not been made, get the decision before the sprint begins.
In LocalPM, you can add blocker risks directly to card descriptions during planning. When the team reviews these risks at the start of the sprint, they can proactively address dependencies before work begins rather than discovering them mid-sprint.
Your sprint goal depends on work flowing smoothly from start to finish. Track your blockers visibly, resolve them quickly, and learn from the patterns they reveal. Your daily standup is the best venue for surfacing blockers early, and your sprint retrospective is where you address the systemic ones.
Learn More
Ready to track and resolve blockers before they derail your sprint? Check out the complete training series:
Watch the Project Management AI Playlist on YouTube
For more project management insights and resources, visit subthesis.com