What is a Blocker Policy?

A blocker policy is your team’s agreed way to surface, manage, and remove impediments so work keeps flowing and forecasts stay trustworthy. It prevents silent ageing of items—the enemy of efficiency, effectiveness, and predictability.

The essentials (keep it tight):

• Define “blocked.” Set a clear threshold (e.g., after 24h with no progress) and get team agreement.

• Make it visible. Flag blocked items loud and clear on your board/tool so anyone can spot trouble at a glance.

• Respect WIP. Blocked items still count toward WIP by default; exceptions are rare and explicit (e.g., long‑term external dependency).

• Actively unblock. Use daily Scrum/stand‑up to focus on blockages. Escalate when item age hits percentile triggers (e.g., 50th/70th on your cycle time). Tackle oldest first; swarm/pair/mob and drop other WIP if needed.

• Tame dependencies & size. Fix internal policy gaps; reduce external friction (e.g., bring skills in‑house, improve vendor pathways). If it’s stuck because it’s too big, slice it smaller.

• Know when to exit. Define criteria to cancel/remove stale items. Don’t delete—mark finished with timestamp and a tag (“abandoned”, “discarded”) to preserve history and uphold Conservation of Flow.

• Improve continuously. Watch Work Item Age and Cycle Time Scatterplots in retros. Treat unnecessary ageing as Flow Debt and adapt policies to pay it down.

Short version: Agree what “blocked” means, make it obvious, keep it in WIP, swarm to fix it, preserve data, and learn fast.