Delivery delays rarely come from one big problem. Much more often, they build up quietly – when work items spend too much time waiting in specific workflow states. This phenomenon can lead to significant inefficiencies and frustration among team members, ultimately impacting project timelines and stakeholder satisfaction.
QA and Engineering teams usually notice this too late, when release dates slip and delivery metrics start to look worse. The screenshots below show how Time in State reporting combined with SLA goals per workflow state in Azure DevOps helps teams understand where time is actually spent and why delivery slows down.
Understanding Delivery Metrics Beyond Total Cycle Time
The first screenshot shows a Time in State report in Azure DevOps. Instead of showing just a total cycle time, the table breaks down each work item by workflow state:
New
In Progress
In QA
Approved
Committed
Total
This view immediately changes how teams read delivery metrics. By analyzing the data in this way, teams can identify specific areas that require attention and improvement.
Looking at the rows, it becomes clear that:
Some work items stay in New for more than a day before anyone starts working on them, indicating a potential bottleneck in task assignment or prioritization.
Active development time (In Progress) is relatively short compared to the total duration, suggesting that while development may be efficient, other stages are causing delays.
Validation and waiting stages such as In QA and Approved consume a large portion of the overall time, highlighting the need for better testing processes or resource allocation.
For example, even feature and technical tasks that move quickly through development still accumulate days of waiting elsewhere. Without Time in State, everything would be in one total number. This makes it hard for teams to find the main causes of delays.
Why This Matters for QA and Engineering Teams
When teams look only at total cycle time, it’s easy to assume that development is the problem. However, Time in State shows a different picture.
QA and Engineering teams can clearly see:
Whether delays happen before development starts, which may indicate issues with project planning or backlog management.
Whether testing and verification take longer than expected, suggesting a need for improved test case design or resource allocation.
Whether work stalls after being approved or committed, which could point to communication breakdowns or unclear ownership.
This helps teams move conversations away from “who is slow” toward “which part of the workflow needs attention.” By fostering a culture of collaboration and continuous improvement, teams can work more effectively together.
Defining SLA Goals per Workflow State
The second screenshot shows the SLA setup panel. Here, teams define service level agreements per workflow state, not per task.
Each SLA rule includes:
A descriptive label (for example, Too Long or Needs Immediate Attention)
A selected workflow state (such as New, In QA, or Committed)
A time threshold that reflects realistic expectations for each state
This approach reflects how work actually flows through Azure DevOps. Different states have different expectations:
Waiting in New may be acceptable for a short time, but prolonged delays could indicate a need for better prioritization.
Time In QA depends on complexity and test coverage, necessitating a tailored approach to testing based on the nature of the work.
Work that is already Committed should not wait too long, as this can lead to frustration and decreased morale among team members.
By setting expectations for each state, teams can avoid unrealistic SLAs. This helps prevent confusion and dissatisfaction.
Making Delays Visible Directly in the Report
The third screenshot shows the same Time in State table – now with SLA rules applied. Cells are visually highlighted when time spent in a specific state exceeds the defined limit.
This makes delays impossible to miss.
At a glance, teams can see:
Which tasks are approaching problematic waiting times, allowing for proactive intervention.
Which workflow states consistently cause slowdowns, providing insights for process improvement.
Where QA, Engineering, or coordination issues may exist, enabling targeted discussions and solutions.
There’s no need to open additional dashboards or export data. The information is available directly where teams already review their work, streamlining the process of identifying and addressing issues.
How Teams Use This in Practice
With Time in State and SLA highlighting in place, QA and Engineering teams can:
Review delivery metrics during sprint reviews or stand-ups, fostering a culture of transparency and accountability.
Quickly identify work items that need follow-up, ensuring that no task falls through the cracks.
Discuss workflow improvements using concrete data, leading to more informed decision-making.
Spot recurring bottlenecks across multiple tasks, allowing for systemic changes that enhance overall efficiency.
Instead of reacting to missed deadlines, teams can address issues while work is still in progress, leading to a more agile and responsive workflow.
Improving Delivery Without Working Faster
Delivery problems rarely appear suddenly. They grow slowly, across workflow states, task by task.
By combining Time in State reporting with SLA goals for each workflow state, QA and Engineering teams get a clear view. They can see how work moves through Azure DevOps and where it slows down.
The screenshots above show how this visibility turns delivery metrics into something teams can actually act on. By leveraging these insights, teams can foster a culture of continuous improvement, ultimately leading to enhanced delivery predictability and satisfaction for all stakeholders involved.
Want to Learn More?
If you have any questions, feel free to leave a comment below or contact us at [email protected].
We’re here to help you optimize your workflow and achieve your project goals.
