Where do Work Items go when they are closed?

Some of the workflow of the Work Items that come in the box in Team Foundation Server is second nature to us at Microsoft, but there are subtle issues which we take for granted that customers are starting to discover for the first time.

This week a customer contacted me because they were having trouble creating a query to show all bugs where "Assigned To = @Me" but didn't see all the bugs they were expecting. The intention was to see all bugs, regardless of state (Active, Resolved, or Closed) but none of the Closed bugs were showing up.

The reason for this is the workflow of bugs when they are closed - by default, the "assigned to" field is cleared when a bug transitions to the Closed state.

This is so that you don't see all the bugs that are now closed (and therefore considered 'done') in any queries for bugs assigned to you. If we didn't do this, then over time, you'd end up with a huge quantity of closed bugs all piling up assigned to you, so it would make simple queries like "assigned to @me" impossible.

If you take a look at the Closed state from the Work Item Definition XML you can see how this is implemented

 <STATES>
    ....
    <STATE value="Closed">
    <FIELDS>
            <FIELD refname="System.AssignedTo">
                <EMPTY /> 
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedBy">
                <REQUIRED /> 
            </FIELD>
            <FIELD refname="Microsoft.VSTS.Common.ClosedDate">
                <REQUIRED /> 
            </FIELD>
        </FIELDS>
    </STATE>
</STATES>

In the XML sample above you can see the changes and rules that automatically get applied to fields when the Work Item is put into the Closed state. In particular, the System.AssignedTo field is cleared by the use of the <EMPTY/> element - this is how the bugs become "unassigned" when they are closed, which was the source of confusion in this case.

Comments

• Anonymous
  May 31, 2005
  Good point on the closed work items. I've had people ask me about that before and my answer was "if you don't like the default behavior, customize the process." You've provided the exact snippet that could be changed. However as you imply, if someone chooses to not empty the assigned-to field, they'll probably want to modify the filters in their work item queries.
• Anonymous
  May 31, 2005
  Why make the AssignTo field empty? Simpley because the results of the queries like "assign to @me&quot; will be too huge? In our projects, if the AssignTo filed is empty which sometimes means something special, the bug may be assigned to some specific person. I think clear the AssignTo filed when the bug is closed by default will confuse many developers outside Microsoft.
• Anonymous
  May 31, 2005
  Bruce, that's definitely something that organizations are going to need to take into consideration. For reporting, & tracking purposes I still think it makes sense for a bug to not remain assigned to a developer - the items assigned to me should be the items I need to take some action on in order to move closer to the project goals.
  
  However, there are alternatives to the approach in the default Work Item Types that I describe here. In fact at Microsoft, for historical reasons, we don't set the assigned to field to Empty - but instead we assign the bug to "Closed" (which we implement in the Workflow section of the WIT XML). This achieves the same effect by moving the bug off the developer's plate - but it means that you can continue to use your special meaning of assigned to being empty.
  
  Let me know if you'd be interested in seeing what this looks like in the WIT XML definition
• Anonymous
  June 04, 2005
  Visual Studio Team System
  
  
  Bill Sheldon from InterKnowlogy has an item in the June 3rd edition of...
• Anonymous
  June 15, 2009
  PingBack from http://workfromhomecareer.info/story.php?id=22742