“Why has this task been in ‘Doing’ for 357 days?”
If you’ve ever asked yourself that — good news: the SLA feature in Time in State for Azure DevOps is here to call out the slackers and save your sprints.
🧠 What is SLA?
SLA (Service Level Agreement) is a commitment to meet specific time-based goals. In the world of Azure DevOps and software delivery, it typically means:
“A task should not remain in a particular state longer than X time.”
For example:
A bug should stay in “In Review” no longer than 2 business days.
A feature request should be picked up from “To Do” within 5 days.
With SLAs, you define the time rules that keep your workflow fast and your team accountable.
⏳ What is Time in State?
Time in State measures how long a work item (like a task, bug, or feature) spends in each status of your workflow — such as “To Do,” “Doing,” “Testing,” or “Done.”
It helps answer:
Where are tasks getting stuck?
How long do bugs sit waiting for review?
Are we moving things fast enough between stages?
Think of it like a time tracker that automatically records the time spent in every column of your board.
💡 So, What Is SLA in Azure DevOps with Time in State?
Service Level Agreement (SLA) in Time in State is the amount of time a work item spends in a specific state (like “To Do,” “Doing,” or “Testing”) — and whether it’s sticking to your expected limits.
Think of it as a stopwatch with expectations. Once a task enters a selected state, the clock starts ticking. And if it ticks too long? You get visual alerts. No more surprises when “that one bug” has been stuck in QA since last fiscal quarter.
📌 Definition Recap:
SLA: A predefined time threshold for a work item to stay in a specific state.
State: A step in your workflow, like “To Do” or “Doing.”
SLA breach: When the time in state exceeds your set threshold.
🛠️ How to Set Up Your SLA
It’s as easy as making a coffee ☕. Here’s how to do it without leaving your report screen.
1. Hit the SLA button
At the top-right of your Time in State grid, click the “SLA” toggle. Boom—you’re in.
2. Define Your SLA Rule
You’ll see a setup box with a few juicy fields:
SLA Name: Like “QA Timeout” or “Critical Fix SLA.” Go wild—but make it clear.
SLA Color: Choose red, yellow, neon green—whatever says “Hey! Look at this!” to your team.
State: Pick the state to monitor (e.g., “Doing”).
Time Goal: The max time allowed, like
25d(25 days) or4h(4 hours).Turn On/Off Toggle: Instantly activate or pause a rule. Handy for testing.
Delete Rule: Click the little trash can if you change your mind.
3. Add More SLA Rules
Click “+ Add SLA” to define additional SLAs for other states or urgency levels. No limits!
4. Save It All
Once you’re happy, smash that Apply button. 🎉
🎨 Visual Feedback You Can’t Miss
Once your SLAs are active, the report grid comes to life with real-time visual alerts:
Color-coded cells show you exactly which work items have exceeded your thresholds.
You can easily scan and spot bottlenecks.
Customize SLA color logic for early warnings vs. critical breaches.
⏳ Workday Awareness: SLAs only count working hours based on your calendar settings. No false alarms because of weekends or holidays—nice.
👥 Who Needs SLA for Time in State?
Spoiler: Almost every role in your delivery process.
| Role | Why They Need It |
|---|---|
| Project Managers | Stay ahead of blockers and missed deadlines. |
| Scrum Masters | Ensure WIP limits are respected and workflows stay lean. |
| QA Leads | See if tasks sit too long in “Ready for QA.” |
| Customer Success | Monitor service promises and fix delays fast. |
| Developers | Know when tasks get stuck waiting on reviews or approvals. |
| Product Owners | Make better backlog and delivery decisions. |
✅ SLA Use Cases
Here are real-world scenarios where this feature shines:
🐞 1. Bug stuck in “In Review”
Set an SLA of 2 days for “In Review.” Get a visual alert if a developer forgets to merge it.
🚀 2. Feature idle in “To Do”
Add an SLA for “To Do” of 5 days. If it’s not picked up in time, you know to reprioritize or ping someone.
📋 3. Test Case delayed in “QA”
Want to make sure testers don’t have a 2-week backlog? Set a rule for max 3 days in “QA.”
🏁 4. Ensure SLA compliance for customers
If your company has formal SLAs (e.g. “Respond to bug reports within 2 days”), this tool makes it visible and auditable.
📚 Real Example: Multi-Level SLA Rules
Let’s say you’re watching the “Doing” state like a hawk.
You could set:
Warning SLA: 25 days → turns yellow
Critical SLA: 35 days → turns red
Result? Same work item, two rules tracking in parallel. You get nuanced alerts based on urgency.
This is a game-changer for teams juggling bugs, features, and fire drills at the same time.
🤖 Why SLAs Matter (a lot)
🔍 Transparency: Everyone sees where things are stuck.
🧠 Better Planning: Know which states need a process rethink.
⚡ Faster Delivery: Eliminate silent delays.
💬 Customer Satisfaction: Meet internal or external SLAs with confidence.
🔄 In Beta: Help Us Make It Better
This feature is fresh out of the lab and currently in Beta. Got feedback or an idea to improve it?
👉 Fill out our SLA Feedback Form
📬 Or shoot us a note at [email protected]
🧪 Haven’t Tried Time in State Yet?
Why wait? This SLA feature is just one of many time-tracking superpowers.