How to Track Blocked Work Items and SLA Breaches in Azure DevOps

Blocked work is not just work that cannot move. It is a delivery promise that now depends on a decision, person, system, or another team. Azure DevOps can help teams record blockers, but the real value comes from a consistent operating rule: every material blocker has a reason, owner, expected resolution, and escalation path.

Without that rule, a “Blocked” tag becomes a graveyard of work that everyone has seen and no one owns.

Catch Up AI approaches blocker tracking as an ownership workflow: make the dependency visible, assign the next action, and escalate according to delivery impact.

Decide what “blocked” means for your team

Define a blocker narrowly enough to remain meaningful. A work item is blocked when the current team cannot make planned progress because it is waiting on something outside the person’s immediate control. Examples include:

• An unresolved cross-team dependency.
• A product or architecture decision required to continue.
• Missing access, environment, data, or vendor response.
• Approval, compliance, or security review that is now on the critical path.
• A production incident consuming the work capacity needed to finish.

“This work is difficult” or “I have not started yet” should not be a blocker. Those are different signals that need different management responses.

Create one consistent Azure DevOps convention

Azure DevOps teams may track blocked work with a tag, custom field, board field, state, or linked dependency. The exact configuration matters less than consistency. Choose one primary indicator and document the fields that must accompany it.

If a custom field adds too much friction, begin with a required tag format and an agreed comment template. Good data habits are more useful than a complicated configuration no one maintains.

Build a blocked-work query and review

Create a shared query for active work marked blocked. Include work-item ID, title, state, owner, priority, iteration, date raised, dependency links, and the latest update. Sort it by delivery impact and blocker age.

Then review it on a fixed cadence:

1. Daily within the team: confirm newly blocked work has the required context.
2. Weekly with delivery leadership: review items that threaten the sprint or release.
3. At release readiness: inspect every unresolved high-impact blocker and its fallback plan.

The review should not become a reporting ceremony. It should result in a decision: remove the blocker, change scope, escalate the owner, sequence work differently, or adjust the release commitment deliberately.

Use response expectations, not a fake universal SLA

Some organizations call this blocker “SLA tracking.” Be careful: the appropriate response time depends on impact. A production-critical security dependency needs a different escalation than an item blocked during early discovery.

Define response expectations by severity:

Measure whether the team responded and whether the blocker was resolved. Do not reward teams for simply removing the blocked label. Otherwise the reporting system will encourage cosmetic updates instead of real progress.

Find patterns, not only individual blockers

Over a few weeks, group blockers by reason and workflow stage. You may find that the same environment access, product approvals, review capacity, or cross-team dependency keeps appearing. That pattern is a system problem worth fixing at the portfolio level.

Use this view alongside Azure DevOps workflow analytics. A long time in QA paired with repeated QA blockers points to a flow constraint, not a series of unrelated tickets.

How Catch Up helps delivery leaders act

A blocker list is necessary, but it can still hide what matters. Catch Up AI's solution for engineering leaders helps connect blockers with aging work, dependencies, and commitment risk. The Catch Up Azure DevOps extension helps leaders focus on the exceptions that require a decision. The insight should always show the underlying work and context so the team can validate it.

Questions leaders ask

How do I track blocked work items in Azure DevOps?

Choose one consistent indicator such as a tag or custom field, then require a reason, owner, date raised, expected resolution, delivery impact, and relevant dependency link. Create a shared query and review material blockers on a fixed cadence.

Should blocked work be a separate state in Azure DevOps?

It can be, but a separate state may distort flow metrics if teams use it inconsistently. Many teams use a tag or field alongside the existing workflow and make the blocker visible on the board. Choose the approach that your team will maintain reliably.

What is a blocker SLA?

A blocker SLA is a response expectation, such as assigning an owner or escalating within a defined time. It should vary by delivery impact rather than applying one arbitrary resolution target to every blocker.

Replace passive status with accountable follow-through

Read how to find aging work items in Azure DevOps next, then install the free Catch Up Azure DevOps extension to identify which blockers need action before a status meeting reveals the delay.