When working with the Reports in Team Foundation Server, you might have noticed yourself that when you change the number of states or even the state names of a certain work item, this will break the out of the box reports. I see a lot of customers that want e.g. to change the state names to their own language.

In reaction to the postings by brain Harry on TFS futures, I brought this discussion to the table and proposed a possible solution to the problem to Randy Miller who is the guy behind the methodologies that ship with TFS. Since it is a pretty simple solution to implement I tought to just post it up here, so you can leverage form it already. We found a pretty easy solution to make reports less depended on the actual state names or state transitions your work item might have. Same solution is applicable to any field like e.g. priority; severity, etc.

consider the “Remaining Work” report that is provided out of the box with the MSF methodologies. This uses the knowledge of the work items that ship with the MSF methodologies and assumes e.g. that work items can be either: Open, resolved or closed. Now this can be true for many teams, but we found that we needed some additional states for a Bug like Analyze, Plan, develop Fix, Fixed, Fix Review, Test, and Released. When you just change the current work item type Bug, you will find that the reports will no longer reflect your work item type because it does not longer have the expected states.

The solution to the problem would be build the reports on known fields in the work items but those fields are not the direct “State” field. You could just introduce an additional field named StatusRollup and have this field always reflect the states you expect in the reports. Now you only have to add logic to the field that it changes to the know states when the actual state of the work item changes. This can be done using the <when> condition on the field, and this would make it react to changes in the states after every change. Now you base the reports not on the State field anymore, but on the StatusRollup field and everyone would be free to change the states as he likes, as long as he updates the mapping of his state names to the ones expected in the reports.

To show you an example you can see the field definition for the statusRollup field we use in our Endeavour Process template definition.

<FIELD name="StatusRollup" refname="InfoSupport.Endeavour.Common.StatusRollup" type="String" reportable="dimension">
<HELPTEXT>Mapping field used for status rollup</HELPTEXT>
<ALLOWEDVALUES expanditems="true">
<
LISTITEM value="Open" /> <!— Work is registered —>
<LISTITEM value="Assigned" /> <!— Work is assigned to someone in the dev team —>
<LISTITEM value="Resolved" /> <!— Work is done, now we go through QA —>
<LISTITEM value="Closed" />       <!— Work is done and tested, ready to ship–>
</ALLOWEDVALUES>
<!—automatic field mapping starts here, change this when changing state names–>
<WHEN field="System.State" value="New">
<COPY from="value" value="Open" />
</WHEN>
<WHEN field="System.State" value="OnHold">
<COPY from="value" value="Closed" />
</WHEN>
<WHEN field="System.State" value="Analyze">
<COPY from="value" value="Open" />
</WHEN>
<WHEN field="System.State" value="Plan">
<COPY from="value" value="Assigned" />
</WHEN>
<WHEN field="System.State" value="Develop-Fix">
<COPY from="value" value="Assigned" />
</WHEN>
<WHEN field="System.State" value="Review-Fix">
<COPY from="value" value="Resolved" />
</WHEN>
<WHEN field="System.State" value="Test">
<COPY from="value" value="Resolved" />
</WHEN>
<WHEN field="System.State" value="Rejected">
<COPY from="value" value="Closed" />
</WHEN>
<WHEN field="System.State" value="Closed">
<COPY from="value" value="Closed" />
</WHEN>
</FIELD>

Now we changed the default reports to work with the StatusRollup field (which was less easy to doJ) and when someone wants to change the states in his project when using our process template, the reports will keep doing their work regardless of the state names they have chosen.

CTO at Xpirit, Microsoft Regional Director, Visual studio ALM MVP, Speaker, Pluralsight Author and IT Architect Consultant