Work item queries are one of the most underused features in Azure Boards. They let you view, filter, and sort your work so you can decide what to act on, and they can power charts on dashboards and wiki pages. When you save a query to Shared Queries instead of My Queries, everyone with access to the project can run it. A few well-chosen shared queries can quietly keep a Scrum Team honest.
Here are the ones I'd create first. Most of them aren't about reporting. They're about surfacing smells.
Health of the Product Backlog
- Open impediments. The whole team, and especially the Scrum Master, should keep an eye on these. Surface them on a dashboard or wiki page so they don't get lost.
- PBIs assigned to someone other than the Product Owner. In Scrum the Product Owner owns the Product Backlog items, not individual Developers. Empty assigned-to values are fine; a Developer's name on a backlog item is a smell.
- New or approved PBIs with tasks. It's wasteful to create tasks ahead of Sprint Planning. This query finds the items where someone got ahead of themselves.
- Approved PBIs without acceptance criteria. If a PBI is approved but has no acceptance criteria, how will the team know what the expectations are or when development is done?
Hierarchy hygiene
If you use Epic and Feature work items, a couple of structural queries help you spot orphans before they bite.
- Features without links to epics. Assuming you're using epics, it's useful to see the unparented features.
- Features without links to PBIs. Assuming you're using features, it's useful to see the ones with no children, because a feature with nothing under it usually means refinement stalled.
None of these queries scold anyone. They just make reality transparent. A team member runs the impediments query during the Daily Scrum, the Product Owner runs the assigned-to query before refinement, and the Scrum Master glances at the "tasks created too early" query before Sprint Planning. The smell shows up before it becomes a habit.
A small warning, because transparency cuts both ways. A query is information, not a weapon. The goal is to help the team self-manage, not to give anyone a stick to wave at individuals. Use these in the spirit of inspection and adaptation, surface them where the team can see them, and let the team decide what to do about what they find.
Save them to Shared Queries, organize them in a folder, and you've built yourself a lightweight checklist that runs itself. Sounds like good Scrum to me.