Category Archives: 5298

Documentation: Customizing Work Item Types

Work Item Type Customizations are well documentedCustomizing Work Item Types
Work Item Type Schema Reference

(Thanks to KathrynE)

Update (Aug 8th, 2011): How to get in IntelliSense when editing WITDs and where to download the XML schema is explained in this blog post by Allen Clark from Microsoft.

Setting Remaining Work to Zero when closing a work item in TFS


How can I make sure that the "Remaining Work" field is set to 0 when the work item is closed (for example when associating a work item during checking-in)?

Short Answer:

You can achieve this using the <COPY> rule on the transition to the "Closed" state.

Step-by-Step instructions:

  1. For the desired transition (in this example from "Active" to "Closed").

    Edit the Workflow Transition with Process Template Editor (part of TFS Power Tools)

  2. Add a field reference to "Microsoft.VSTS.Scheduling.RemainingWork"

    Choose the desired field 
  3. Add a new rule of type "COPY"

    You can use the copy rule to set values
  4. Choose From = "value" and enter value = "0"

    The copy rule sets a value to a field
  5. The resulting XML should look something like

     XML under the covers defines our new rule
  6. Verification: After transitioning a task work item from "Active" to the "Closed" state "Remaining Work" is set to zero.

    Work Item History shows the new rule in beeing applied on the state transition. 

Specifying a user upfront or: How is the developer supposed to know who will be the responsible tester?

In a small team this sounds like oversize, but in mid-sized large teams it’s common that you do not know who is going to be the tester.

Looking at the Bug workflow from MSF Agile:

  1. while "Active" the project lead decided if and when the bug is going to be fixed and assigns it to the responsible developer.
  2. between "Active" and "Resolved" is where the developers implements the fix.
  3. between "Resolved" and "Closed" is where the tester verifies the fix.

MSF Agile Bug workflow

When the developer finishes coding he changes the state from "Active" to "Resolved", e.g. by checking in and associating the changeset with the work item.

But by doing so the work item is still assigned to him. In our scenario he doesn’t know who will be the responsible tester to verify the fix. So who knows?

The project lead might have that information. So either we assign it back to the project lead to make him assign it to as tester or we make the project lead specify the tester upfront (with the ability to change it afterwards if necessary).

In this example we’ll implement the second approach.


Ask for the Tester when creating the bug and automatically it for the transition from "Active" to "Resolved"

Required Work Item Customization

Step 1: Add a new string field to hold the tester
In this example we will make it a required field (<required/>) and ensure that it contains a valid user (<validuser/>).

<FieldDefinition> type="String" name="Tester" refname="TeamSystemPro.Samples.Tester">

Step 2: Add a rule to the transition from "Active" to "Resolved"
Automatically copy the value of the tester field to the Assigned to field.

<FieldReference refname="System.AssignedTo">
  <COPY from="field" field="TeamSystemPro.Samples.Tester" />


When creating a new bug it’s now required to select a Tester before it can be saving.

Creating a new bug requires a tester to be specified

When choosing "Resolved" for the state "Assigned to" will be automatically filled with the contents from the "Tester" field.

Transitioning to resolved copies the tester to the Assigned to field

The history correctly shows the change in the "Assigned To" field from the developer (here: "Neno Loje" to the tester (in this case: "Administrator")

History displays the change in Assigned to field

Happy Customizing!

Using TFS for non-development projects

Team Foundation Server is easily customizable and equipped with a general purpose workflow or state machine. So you might ask yourself: why not put a non-development or rather related process in TFS instead of using separate software.

Showcase #1: Lead Management

AIT_TeamSystemPro_Team_klein_120x58Since here at AIT TeamSystemPro Team we are TFS consultants we decided to not use a commercial CRM tool for managing our leads but rather customize a team project in TFS for this matter.

Here are a few impressions of the experience:

Leads in Excel 

Work Item queries:

Work Item Queries for our Leads

Work Item layout:

Leads - Work item Layout

in Outlook (via TeamCompanion)

Leads in Outlook

Leads in Outlook (2)

The pretty simple workflow behind it:

lead workflow 

Showcase #2: Customer Support

Needless to say that the TFS support that we offer is tracked using work items as well:

Support Case work item

Customer Support Queries

Showcase #3: List of managed TFS instances

Every TFS instance that we manage has a corresponding record:


Your Feedback

Do you have an interesting idea or have you used your TFS to support a non-dev related process? Feel free to leave me a comment or use the contact link – thanks!

Using rich HTML descriptions instead of plain text


Allow rich HTML formatting in description fields of the MSF Agile process template.

Note: The MSF CMMI process does support HTML formatting by default. In order to use it you have to enable the formatting toolbar (see Step 6 below).

Work Item Customization

Step 1: Add a new HTML description field

Since the System.Description field is defined of type string as opposed to type HTML we need to create a new field:



Step 2: Change the work item layout

Use your own HTML field instead of System.Description


Step 3: Refresh Work Item cache

Right-click "Work Items" in Team Explorer and select "Refresh".


Step 4: Enable the formatting toolbar

Right-click on the Visual Studio toolbar, find and click "Formatting":


A new toolbar will appear:



Click into the description field and use the toolbar to format your input:



Optional Step 5: Copying the old descriptions to the new HTML field

It would be a pity to loose the existing descriptions so let’s write a small utility using the Team Foundation Object model to copy the "old" descriptions to the new HTML field:

static void CopyOldDescriptions()
    // TODO: Change these values:
    string tfsName = "servertogo";
    string tfsProjectName = "WorkItemCustomization";
    string tfsHtmlDescriptionFieldName = "DescriptionHtml";
    string tfsWorkItemType = "Task";

    using (TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(tfsName))
        WorkItemStore wit = (WorkItemStore)tfs.GetService(typeof(WorkItemStore));
        WorkItemCollection result = wit.Query(String.Format("SELECT [System.Id] FROM WorkItems WHERE [System.TeamProject] = '{0}' AND [System.WorkItemType] = '{1}'", tfsProjectName, tfsWorkItemType));
        List<WorkItem> affectedWorkItems = new List<WorkItem>();
        foreach (WorkItem wi in result)
            if (wi.Description.Length > 0)
                // Set new description
                string value = (string)wi[tfsHtmlDescriptionFieldName];
                if (String.IsNullOrEmpty(value))
                    wi[tfsHtmlDescriptionFieldName] = wi.Description.Replace("\n", "<br>");
                    wi[tfsHtmlDescriptionFieldName] += "<br><p>Old description:</p><p>" + wi.Description.Replace("\n", "<br>") + "</p>";

                // Delete old description
                wi.Description = String.Empty;


        if (affectedWorkItems.Count > 0)
            MessageBox.Show("Items updated: " + affectedWorkItems.Count);
            MessageBox.Show("Nothing to do.");

Happy formatting. :-)


Workflows of MSF Agile and CMMI Process Templates for TFS

When trying to decide which of the two MSF Process Templates – Agile vs. CMMI Process Improvement – for TFS is the right starting point for your company, it helps to compare the work item types and its workflows.

You can download the full guidance from:

MSF for Agile Software Development

featuring 5 work item types: Bug, Requirement, Quality of Service Requirement (QoS), Risk and Task.

Work Item Type: Bug


Work Item Type: Scenario


Work Item Type: Quality of Service Requirement (also known as “technical requirement”)


Work Item Type: Risk


Work Item Type: Task


MSF for CMMI Process Improvement

featuring 7 work item types: Bug, Requirement, Change Request, Issue, Review, Risk, Task

Work Item Type: Bug


Work Item Type: Requirement


Work Item Type: Change Request


Work Item Type: Issue


Work Item Type: Review


Work Item Type: Risk


Work Item Type: Task


As a personal note:

Both templates are a great starting point. The agile template might be a bit more lightweight whereas the CMMI template might fit more the vocabulary and processes that you are used to.

However, both are really just a starting point. In customizing the process you get way more out of TFS than with just using the built-in process templates.

Specifying a minimum size for controls on the work item form

If you try to set the minimum size for a control you now need to specify a SizeType like “(50,100)” instead of “50,100”.

Error message (from witimport.exe):

The ‘MinimumSize‘ attribute is invalid – The value ‘50,100’ is invalid according to its datatype ‘SizeType‘ – The Pattern constraint failed.

Using a minimum size you can create multiple large text boxes on the work item form layout: