Fragmented Thought

Azure DevOps - My work items

A dashboard replacement to keep your team in the know.

Azure DevOps - My work items - Dashboard
By

Published

Lance Gliser

I've worked with Azure DevOps in two companies now. In both cases, it's always been a constant struggle to decide if you should have one project, with multiple teams that have their own sprints and areas or multiple projects. It's hard to say what is "right." The standard "it depends" applies based on things like sensitive context, external team members, and organizational access. Both of my previous companies choose to go with multiple projects. Once started, it's a decision that quickly becomes unwieldy unless to use the stock tools.

Default - "My work items"

One of the worst offending tools, perhaps even if you choose only a single project is "My work items". There's a slightly stronger version suggested in their working across projects documentation. Neither provides you enough context to understand the work.

A good view of your dashboard needs to identify:

  • The project ✅
  • The iteration or sprint
  • The id ✅
  • The type ✅
  • The title ✅
  • The status ✅
  • The parent item
  • The priority

Bonus points for:

  • The remaining work (in hours)
  • Collapsible hierarchy to hide what you don't need
  • A method to open as a query for full functionality.
  • Sorting control

Score: 5/12

It's not that I refuse use it, but there surely is better.

Custom - "My work items" Dashboard

Enter our new beauty, a collection of widgets driven by queries:

A dashboard with original estimates, completed work, type breakdown, and remaining items with context.

For sheer joy, let's run the numbers:

  • The project ✅
  • The iteration or sprint ✅
  • The id ✅
  • The type ✅
  • The title ✅
  • The status ✅
  • The parent item ✅
  • The priority ✅

Bonus points for:

  • The remaining work (in hours) ✅
  • Collapsible hierarchy to hide what you don't need ✅
  • A method to open as a query for full functionality. ✅
  • Sorting control ✅

Score: 12/12

Let's break down how it was built in parts. The key is the use of queries set for cross project access. We'll define two:

My completed work

Query across projects: [X]
Type of query: Flat list of work items
Work Item Type: = Task
And State: <> Closed
And State: <> Done
And Closed Date: >= @StartOfDay('-90d')
And Assigned To: = @Me

Column options:

Fields:

  • Id (purely for reference)
  • Title (purely for reference)
  • Assigned To
  • Original Estimate
  • Completed Work
  • Activity

This query will be for the three pie charts at the top of the dashboard. You can add three Charts for work items to aggregate the query items to help your team understand their estimated vs actual hours and work types.

My open work

Query across projects: [X]
Type of query: Tree of work items

Filters for level work items:
Work Item Type: = User Story Or Work Item Type: = Bug
And State: <> Closed

Filters for linked work items:
Work Item Type: = Task
And State: <> Closed
And State: <> Done
And Assigned To: = @Me

Column options:

Fields:

  • Iteration Path
  • Id
  • Title
  • State
  • Priority
  • Assigned To
  • Story Points
  • Original Estimate
  • Remaining Work
  • Completed Work
  • Activity

Sorting:

  • Priority ascending
  • Iteration Path ascending
  • Remaining Work ascending

This query will be used to pull items into a query result which will elect to omit some of the fields for brevity. Users in need of more context or mass editing can use the link to view the additional columns you define that help customize the context required for your company.

Hopefully this makes it easier to understand what, why, and in what order you need to take on. If anyone happens to know a means of adding your capacity from a project, I'd love to see that added.

Happy building, and cheers!