I got a question from a customer yesterday as part of an upgrade to Azure DevOps 2020. He was telling me that some of the work items that were assigned to him were missing from the "Assigned to me" work item query results. He showed it to me and -- sure enough -- they were missing. I was stumped.

(TL;DR: it's a feature not a bug.)

Setting Up to Recreate the Problem

Let's say that I create a new Team Project using the Scrum process template (or Agile) and then create some work items and assign them to me. Then I go to the Assigned to me work item query. When the work items are new, all the work items that I expect appear in the query results in the Assigned to me query.

Next, I'll modify one of the items and set the status (System.State) to 'Removed'.

When I go back to the Assigned to me query and refresh it, PBI A is now missing from the list.

The Problem: Select 'Removed' State Filter and Get No Results

Here's where my customer was really getting confused. Heck! This is where I got really confused, too! In the filter bar for the Assigned to me query, let's set the States filter to show us Removed items.

This should show us the Removed items that are assigned to me, right?

Wrong.

The Problem Gets More Confusing

At this point, I figured that there was something weird with the work item query. Since this is a query that's auto-generated for us by Azure DevOps, I suspected that what it's generating was weird and I wanted to take a look. In order to see what's being generated as a work item query, you can click the Open in Queries button. Clicking this button takes you to the work item query editor and it allows you to riff off of the generated query and then optionally save it.

I clicked the Open in Queries button and I expected to see those same 3 work items and that the Removed work item would be missing.

The answer? That'd be a big ol' nope. The query showed me all of my assigned work items INCLUDING the one that was Removed.

So I clicked on the Editor tab to view the query builder. The query looked fairly normal. It queries for "Assigned To = @me" and then "State not in Done, Closed, Inactive, Completed".

Looking at that query definition, it makes sense that the Removed item is showing up because there's nothing in the query saying to discard the Removed state values.

What is going on?!?!?

At this point, I had to admit that I was stumped. There's clearly some kind of difference between the query in the editor and the actual Assigned to me query that's being generated by Azure DevOps. Could it actually be a bug?

I decided to go read the documentation. When I scrolled down to the View work items section, there's a bullet that says that the Assigned to me view "does not include items moved to the Removed state". Essentially, this means that this behavior (while confusing) is by design.

One thing I noticed while I was reading the documentation is that Microsoft is NOT calling these "work item queries". Instead they're calling them "views" or "pivot views". That helped me to understand why this is confusing -- they're intending this to be a simple way to view your data without having to worry about the intricacies of work item queries.

I guess that kind of makes sense because anything that's set as "Removed" is intended to be treated as if it were deleted. Put another way, "Removed" is a "soft delete" state. It's still there but you have to really go looking for it to get it back.

Summary

It turns out that my customer had stumbled onto something that was a little confusing. It's not really a work item query -- it's a "list" or a "pivot list" -- and ignoring Removed items is by design.

If you need to view your Removed work items, you should create a separate work item query to see those items.

I hope this helps.

-Ben

-- Looking for help with Azure DevOps work items and work item queries? Trying to use Azure DevOps to streamline the work for your Scrum teams? Want some help with your QA testing processes or automated build/release pipelines? We can help. Drop us a line at info@benday.com.