How to Identify Aging Tasks in Azure DevOps in Minutes

Identify aging tasks in Azure DevOps using improved workflow visibility, a detailed work item aging report, and cycle time tracking to avoid delays.

In every development team, there are tasks that quietly sit in the same state for too long.

They don’t look urgent.
They don’t trigger alarms.
They don’t block deployments.

And that’s exactly why they’re dangerous.

If you don’t actively Identify Aging Tasks, they remain invisible inside your workflow, slowly extending cycle time, delaying releases, and creating hidden bottlenecks.

The challenge isn’t tracking statuses.
The challenge is recognizing how long work has actually been sitting there.

That’s where Time in State for Azure DevOps becomes essential.

Why Aging Tasks Are a Hidden Risk

In Azure DevOps, work items typically move through stages and at a glance, everything may seem fine. But what you don’t immediately see is:

How many days a task has been in “Active”
How long a bug has been waiting for review
Which work item has been sitting in “Testing” without movement

Without time visibility, these aging tasks become invisible blockers.

What “Aging” Actually Means

An aging task is not necessarily overdue.

It’s a work item that has spent more time in a specific state than expected based on your team’s normal delivery cycle.

For example:

Most tasks stay in “Code Review” for 1-2 days
One task has been there for 6 days

That’s a signal, not necessarily a failure, but a sign that something needs attention.

Step 1: Open Time in State Analytics

With the Time in State extension for Azure DevOps, you can instantly see how long each work item has remained in every stage of your workflow.

Instead of checking history manually, the report shows:

Time spent per state
Total lifecycle duration
Transition history
Current state duration

This transforms Azure DevOps from a status tracker into a time-based workflow analysis tool.

At first glance, everything looks normal.

But look closer.

You can immediately spot how long each task has stayed in each workflow stage.

For example:

“Create password reset functionality” spent 1d 18h 43m in New
“Optimize database queries for audit logs” shows significant time across multiple states
Some items are still marked as Unassigned, which may signal ownership gaps

This is where aging starts to become visible.

Step 2: Filter by Current State Duration

Inside the Set SLA panel (time limits per state), you define:

Custom label (e.g., Needs Immediate Attention!, Too Long, At Risk)
The specific workflow state (New, In QA, Committed, etc.)
The time threshold (e.g., 2d 01h, 1d 05h, 6h 30m)

Once applied, the system automatically highlights items exceeding those thresholds.

This transforms the report from passive data into an active monitoring tool.

Instead of asking:

“Has anything been sitting too long?”

You immediately see:

“This task has exceeded its expected duration.”

Step 3: Act Before Delays Spread

Now, instead of manually scanning numbers, you see:

🟠 Orange cells → tasks approaching a critical time threshold
🔴 Red cells → tasks that have exceeded acceptable limits

For example:

“Optimize database queries for audit logs” is highlighted in red after spending 3d 22h 7m in one state
“Design UI/UX Mockups” shows extended time in New
QA-related stages also show prolonged durations

This visual layer instantly reveals which work items are aging, without calculating anything manually.