Team Foundation Server 2010 and add-ons
We use Team Foundation Server (TFS) 2010 to manage our projects including source control, product backlogs, tasks, and bug tracking.
Our setup consists of:
- Team Foundation Server 2010
- Microsoft Visual Studio Scrum 1.0 (process template)
- TFS Power Tools
Customize a TFS work item
When you install TFS Power Tools you get an additional menu option called Process Editor under Tools in Visual Studio 2010:
The Process Editor allows you to edit work item types, either globally or for a specific TFS project.
For example, we can modify the Task work item type to add a custom field by clicking Work Item Types and selecting Open WIT from Server:
This brings up a dialog with the available TFS projects. So, if we want to modify the Task work item type for our website’s TFS project we’ll simply expand its node and select the Task work item type:
We click New on the Fields tab to add a custom field:
Next, we give our new field a name, a reference name, and optionally a description:
Next, let’s add a rule for specifying available value options for this field. We click the Rules tab and click the Add button:
We’ll select the SUGGESTEDVALUES option in the next dialog…
…and then we set group restrictions (optional) and click the New button to add our options:
When we’re done we can switch to the Layout tab to add our field to the work item editor:
We’ll set a label for the control and select the field we created earlier:
Now, if we create a new Task work item…
…we’ll be able to see our new custom field in action:
Modify a TFS work item workflow
To modify a workflow you open up the work item associated with the workflow. We could for example modify the workflow for the Bug work item type in order to add additional states to make it fit our work process:
We click the Workflow tab to edit the workflow associated with the Bug work item type:
The original workflow for the Bug item type in the Visual Studio Scrum 1.0 template takes bugs from New to Approved to Committed and finally to Done – unless they are Removed:
We want to rename some of these different states, and also add a few new ones. We do this by pulling up the standard Visual Studio toolbox which, when a workflow is being displayed, gives a few basic – but useful – artifacts to customize the workflow:
Renaming a workflow state
First off we want to rename the somewhat confusing “Approved” state to “Verified” (indicating that the reported bug is indeed a bug), so we simply double-click the red state object and change its name to “Verified”:
We also change the name of the “Committed” state to “In progress”:
When the bug is done we consider it to be in need of approval, so we change the name of the “Done” state to “Awaiting approval”:
In order to allow a product manager, or other similar role, to approve the resolution of a bug we need to add two additional states: “Accepted” and the less popular “Not accepted”. We do this by adding a new State object to the workflow:
We double-click the new State object and name it “Accepted”. We repeat this process for the “Not accepted” state:
To connect the workflow states we click the Transition Link tool in the toolbox and then we click the “Awaiting approval” state followed by the “Accepted” state. We repeat this for the “Not accepted” state:
When two state objects have been connected by a transition link we see a new blue transition object. We can click the downwards-pointing double arrow to modify the transition object:
Each transition must be given a reason which explains why the workflow progressed from one state to the next.
To set the reason why the workflow goes from “Awaiting approval” to “Accepted” we double-click the transition object connecting them. This brings up the Workflow Transition dialog:
We switch to the Reasons tab to set the reason(s) the change in state can occur. Simply click New to add a new reason:
In this case we’ll say that there are two reasons a Bug item can go into the “Accepted” state: 1) the customer has accepted the resolution (this is the default), or 2) the bug was accepted and given the OK by a developer.
First we’ll add the default reason, when the customer has accepted the fix:
Note that field rules can be applied on the Fields tab if necessary.
We’ll also add the second reason a Bug can become “Accepted”, when a developer gives it the OK:
So, we now have two reasons for a Bug going into the “Accepted” state:
We’ll repeat this process for the transition from “Awaiting approval” to “Not accepted”.
We will also add another transition link to allow the Bug item to go from “Not accepted” to “In progress” to allow us to have another go at fixing the bug.
All in all, our revised workflow looks like this:
Once a Bug is “In progress” it can be set as “Awaiting approval” (because we believe it has been fixed). The customer can agree which would make the bug resolution “Accepted”. If the customer does not agree, the Bug will go into a state of “Not accepted” which in turn means we can start working on it again by setting the state to “In progress”.
We can now try and modify the State field for a Bug item to see the workflow in action. For example, we see that from the “Awaiting approval” state we can go to the “Accepted” or “Not accepted” states:
Note: The workflow could optionally be complemented with a transition link from “Accepted” to “Not accepted” with a reason saying the bug was re-opened.