Azure DevOps Queries That Actually Help You Get Work Done
Practical Azure DevOps query examples you can use today — from tracking your recent changes to finding stale work items nobody has touched.
Azure DevOps ships with a handful of built-in queries. “My Bugs,” “Assigned to me,” that sort of thing. They work fine as a starting point, but most developers never go further. The query editor sits there with all this power, and people just use the defaults forever.
That’s a shame, because a few well-crafted queries can replace a lot of the “let me go hunt for that work item” time that eats into your day. Here are the ones I actually use.
A quick primer on the query editor
If you haven’t dug into it before: go to Boards > Queries in your Azure DevOps project, then click New query. You’ll get a visual editor where each row is a filter clause — a field, an operator, and a value. Stack them up with AND/OR logic.
The key fields you’ll use most:
- Assigned To — who owns the item
- State — Active, Closed, New, Resolved, etc.
- Work Item Type — Bug, User Story, Task, Epic
- Changed Date — when the item was last modified
- Area Path — the team or component area
- Priority — 1 through 4
Azure DevOps also gives you macros like @Me (current user), @Today (current date), and @Project (current project). These are what make queries reusable — you write them once and they work for anyone on the team.
Work items I changed this week
This is probably the most useful query you can build. It answers the question you get in every standup: “what have you been working on?”
| Field | Operator | Value |
|---|---|---|
| Changed By | = | @Me |
| Changed Date | >= | @Today - 7 |
That’s it. Two clauses. You get every work item you’ve touched in the last seven days, regardless of whether it’s assigned to you. This catches items you commented on, moved to a different state, or updated the description for — not just the ones sitting in your name.
Sort by Changed Date descending and you’ve got a reverse-chronological view of your week.
Bugs assigned to me, sorted by priority
The built-in “My Bugs” query exists, but it doesn’t sort by priority, which makes it close to useless when you’ve got 15 bugs and need to know which one matters most.
| Field | Operator | Value |
|---|---|---|
| Work Item Type | = | Bug |
| Assigned To | = | @Me |
| State | <> | Closed |
| State | <> | Removed |
Set the sort order to Priority ascending (so P1 shows up first), then by Changed Date descending as a tiebreaker. Now your bug list is something you can actually work from top to bottom.
Items updated in the last 24 hours in my area
This one is great for catching up after being out for a day, or just seeing what’s moving around you.
| Field | Operator | Value |
|---|---|---|
| Changed Date | >= | @Today - 1 |
| Area Path | Under | your-project\your-team-area |
Replace the area path with wherever your team works. The Under operator is important — it includes all child areas, so if your team has sub-areas for different components, you get everything.
This is also useful as a shared team query. Save it under Shared Queries and anyone on the team can see what changed since yesterday.
Stale items nobody has touched
Every project accumulates zombie work items — things that were created, maybe discussed once, and then left to gather dust. This query surfaces them.
| Field | Operator | Value |
|---|---|---|
| Changed Date | <= | @Today - 30 |
| State | <> | Closed |
| State | <> | Removed |
Thirty days with no changes and still open? That’s a candidate for closing, re-prioritizing, or at least a conversation about whether anyone still cares. Adjust the number to fit your team’s rhythm — some teams use 14 days, some use 60.
Add an Area Path filter if you only want to see your team’s stale items rather than the whole project’s backlog of forgotten work.
My items across all projects
By default, queries run against a single project. If you work across multiple Azure DevOps projects (and a lot of developers do), you need a cross-project query.
When creating a new query, check the Query across projects toggle at the top of the editor. Then set up your clauses:
| Field | Operator | Value |
|---|---|---|
| Assigned To | = | @Me |
| State | <> | Closed |
| State | <> | Removed |
Now you get a single view of everything on your plate across every project in the organization. This is one of those features that’s been in Azure DevOps for years but almost nobody uses because the toggle is easy to miss.
Going deeper with WIQL
The visual query editor covers most cases, but if you need something more complex — nested logic, custom fields, or queries you want to store in source control — you can write WIQL (Work Item Query Language) directly.
WIQL looks like SQL but operates against the work item store. Here’s the “changed this week” query in WIQL:
SELECT [System.Id], [System.Title], [System.State], [System.ChangedDate]
FROM WorkItems
WHERE [System.ChangedBy] = @Me
AND [System.ChangedDate] >= @Today - 7
ORDER BY [System.ChangedDate] DESCYou can run WIQL through the Azure DevOps REST API, which is handy for automation, dashboards, or integrating with other tools. The WIQL syntax reference in the Microsoft docs is worth bookmarking if you go down this path.
The gap that queries don’t fill
These queries are useful. I use them regularly. But they have a blind spot: they only surface items you’ve modified. If you opened a work item, read through the comments, checked the linked PRs, and closed the tab — that visit doesn’t show up in any query. Azure DevOps simply doesn’t track what you’ve viewed, only what you’ve changed.
That’s the gap TicketHop fills. It’s a Chrome extension that automatically records every Azure DevOps work item you visit. No manual steps, no query setup. Just open a work item and it’s in your history.
So queries give you “items I’ve acted on.” TicketHop gives you “items I’ve looked at.” Together, you’ve got pretty solid coverage — the stuff you changed and the stuff you reviewed, investigated, or triaged without leaving a fingerprint in the system.
You can also attach private notes to any work item for the kind of context that doesn’t belong in a public comment — “this is related to the auth bug Sarah mentioned in standup” or “waiting on the API team before this can move.” It’s useful context that lives with the work item but stays yours.
If you spend most of your day in Azure DevOps, give TicketHop a try. It’s free, takes about 10 seconds to install, and works alongside whatever query setup you’ve already got.