Kanban customizable columns was made publicly available on the March 4 service update, and will be available in the RC version of VS Update 2.

You can read the release notes for an overview of the feature itself. The purpose of this blog post is to talk about what’s going on under the hood of this new feature.

With this feature, we’ve added an additional data element called “Kanban Column”. This stores which column on the team’s kanban board the work item is in. This is separate from, but related to the State field.

When designing this feature, we considered just adding another field to the User Story / Requirement / Product Backlog Item work item types called “Kanban Column”, but that would require existing customers to have to update their work item type definitions to utilize the feature. And, since the board’s column configuration was meant to be scoped to a team, using a “global field” didn’t work well.

Introducing, the WIT Extension

We created a new work item tracking element we call a WIT Extension, which allows you to attach to an individual work item a field and a set of rules dynamically, at run-time, without updating the work item type definition. I underlined that last part, because that’s pretty exciting stuff.

For this feature, we created the Kanban Column WIT Extension, which contains a single field “Kanban Column”, and a set of rules on that field. In this case, the rules ensure that the State and Column are kept in synch, as per the State/Column mappings defined in the Customize Columns dialog. For example, if you have the following column configuration:

We generate rules that look like this:

These rules fire when you drag an item to a Kanban Column, and we automatically update the State:

We also generate the rules in reverse, like this:

So that when you update the State, we automatically update the Kanban Column:

The Kanban Column field is scoped to the team, and appears as follows in the work item history. Note how the field is scoped to [Team Project\Team Name].

How are WIT Extensions attached to work items?

WIT Extensions are only attached to individual work items when those work items appear on a backlog. When an item is added to a backlog, the WIT Extension is attached, the field exists, and the rules are run. If a work item is removed from a backlog, then the WIT Extension is detached from the work item, and the field no longer exists, and the rules are no longer run.

Attaching/detaching is done dynamically via the WIT Extension’s predicate, which defines an expression which, if evaluated as TRUE, will attach an extension to the work item, or detach if FALSE. For each TFS Team, we create a unique Kanban Column WIT Extension that with a predicate that matches that team’s product backlog query. This is done automatically for you when you create the team. On every save, we will evaluate the work item against the set of WIT Extensions (one for every team), and will attach/detach as needed.

For example,. if change the area path, and move the work item from one backlog to another, TFS detaches the extension for the original team, and attaches the extension of the destination team. In the example below, we changed the area path to move it from Team B’s backlog to Team A’s backlog.

The “Extension Marker” field shows whether the WIT Extension is attached or not. You’ll also notice that the Kanban Column has a new value for Team A. How did we know how to do that? The current state of the work item was “Active”. We ran the rules on Team A’s WIT Extension, and the default column for “State=Active” was “Working”, and set it automatically.

Can work items be on multiple boards?

You can configure two teams to own the same area path. Its not recommended, but it is possible. In this case, the work item would have two WIT Extensions attached to it. For example, let’s say both “Team A” and “Team A Clone” are configured to have the same area path. The predicate for the WIT Extension for both teams are identical and both would evaluate as true. In effect, the item appears on two different boards at the same time. But what happens if you change the column on one board? Here’s the answer:

Here is Team A’s board and column configuration:

Here is Team A Clone’s board and column configuration:

The work item “Item 1” is the same work item, but appearing in two different places. What happens, if I drag “item 1” from “WORKING” to “VERIFICATION” on Team A’s board:

TFS will run the rules on both extensions. It will look something like this:

Team A: When Kanban Column = Verification, then State must be Resolved.

Team B: When State = Resolved, then Kanban Column must be one of: “Testing”, if not set to default column (which is Testing)

This will produce a work item revision that looks like this:

As you can see the new WIT Extension paradigm is pretty powerful. We have written it for the Kanban – Customizable Columns feature, but our goal is to expand the functionality to have parity with other work item fields. For example, while the field will show up in the work item history and is available from the object model, it is not available for queries, reporting, excel/project integration, and can’t be displayed on the work item form.

Eventually, we want to allow WIT Extensions to be created by our customers, allow the process to be defined in a much more componentized manner, rather than the monolithic way it is today.

For now, whenever you drag that tile from one kanban column to another, just know that there is a powerful new component in work item tracking that is managing the stuff under the hood.

The truth of the matter is, the “Remaining Work” field on the Task work item is just a dumb integer. You can enter anything you like in it. The only thing that even references what unit it might be in is the little “h” that appears on the task board and on the capacity pane.

If you are installing TFS 2012 on-premise, this little “h” is configurable to be whatever you want. (Unfortunately, it is not configurable for tfspreview.com … yet)

Here’s how:

Step 1: Export the configuration settings to an XML file.

cd C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE

witadmin.exe exportcommonprocessconfig /collection:https://SERVERNAME:8080/tfs/DefaultCollection
       /p:PROJECTNAME  /f:.\CommonConfig.xml

Step 2: Edit the XML file to change your “Remaining Work” suffix.

Locate this line in the XML file:

    <TypeField refname="Microsoft.VSTS.Scheduling.RemainingWork" type="RemainingWork" format="{0} h" />

Edit the highlighted part to be whatever you want. For example, if you estimate in story points, you can change it to “{0} sp”.

Step 3: Import the configurable settings from the XML file

witadmin.exe importcommonprocessconfig /collection:https://SERVERNAME:8080/tfs/DefaultCollection
       /p:PROJECTNAME  /f:.\CommonConfig.xml

Enjoy!

- For Agile, the User Story's state model has been updated to allow you to transition from any state to any other state.

- For Scrum, we did the same for Product Backlog Item and Bug.

- For CMMI, we corrected some bugs where the ResolvedBy, ResolvedDate, ActivatedBy, ActiviatedDate fields were not being set/cleared properly on some transitions.

We have noticed in the industry a desire to move towards a less restriction process flow. The implementation of the kanban board highlighted just how restrictive our work flow was.

For example, for Scrum, if you moved a tile from "New" to "Approved", you couldn't move back again!

This just seemed too restrictive and we fixed it.

It should be noted that we did not update the workflow of Requirements in the CMMI template, as we are assuming if people want this template, they want a more formal control over the work flow.

One backlog to rule them all…

One common practice we’ve seen our customers use is to have a master backlog, which “feeds” several teams. The master backlog is prioritized and maintained, and when it comes time to plan for the next sprint, all the teams gather together and “sign up” for backlog items to work on in the upcoming sprint.

That way, they can ensure that all teams are working on the most important items for each sprint.

This blog post will tell you how to configure and use a master backlog.

Let’s start with a newly created team project: “Demo Project”. When a project is created, a default team is created for that project. This team is the “master” team.

(Many thanks to Hayder Casey, who provided this great write-up on work item tracking custom controls. He’s a developer who works on the TFS Work Item Tracking team with me. Thanks Hayder!)

Custom Controls provide a mechanism to extend the work item form to include user developed controls. It enables various scenarios, that are difficult or not possible using the built in controls such as: extend event-based rules, custom user interface, workflow capabilities. More details about custom control capabilities and restrictions are found in the WIT Custom Controls msdn article.

We have a codeplex project: Custom Control for TFS Work Item Tracking, you can find more details, and source code for useful custom controls.

Implementation

Custom control should derive from System.Windows.Forms.Control and implement IWorkItemControl interface and optionally implement IWorkItemToolTip, IWorkItemUserAction, and IWorkItemClipboard.  These interfaces are in Microsoft.TeamFoundation.WorkItemTracking.Controls.dll

IWorkItemControl

This is the interface that all custom control (actually even built in controls) implements. It provides basic functionality to interact with the workitem object and the form. Let’s take a look at its definition:

    public interface IWorkItemControl

    {

        object WorkItemDatasource { get; set; }

        string WorkItemFieldName { get; set; }

        StringDictionary Properties { get; set; }

        bool ReadOnly { get; set; }

        event EventHandler AfterUpdateDatasource;

        event EventHandler BeforeUpdateDatasource;

        void Clear();

        void FlushToDatasource();

        void InvalidateDatasource();

        void SetSite(IServiceProvider serviceProvider);

    }

WorkItemDatasource
Passes a reference to the WorkItem object (cast it to Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem). During initialization this get set to null, so make you take that into account when using the property.

WorkItemFieldName

The name of the field the control is associated with. However it’s possible for control to not be associated with a specific field. For example the LinksControl always work with the work item links and not associated with a field while the DateTimeControl is always associated with a field.

Properties

A property bag of all attributes specified in the work item form xml for this control. There are a set of standard attributes (Padding, Margin, Dock, …etc ) see The Control element article on msdn for a complete list of attributes. These standard attributes are automatically parsed and applied to your control, so you don’t need to do anything. Besides those you can supply custom attributes, there are no restriction to the attribute name. For example you can specify a color attributes in the xml, then in your implementation you can read this attributes and set your control color accordingly. In 2010 we also allow you to specify an xml element “CustomControlOptionsType”.

Here is the control type schema used for the wit definition, highlighted is new for 2010:

    <xs:complexType name="ControlType">

 <xs:element name="CustomControlOptions" type="CustomControlOptionsType" minOccurs="0" maxOccurs="1" />

<xs:attribute name="FieldName" type="typelib:ReferenceFieldName" use="optional" />

        <xs:attribute name="Type" type="ValidControlsType" use="required" />

        <xs:attribute name="Label"     type="LabelType" use="optional" />

        <xs:attribute name="LabelPosition" type="LabelPositionType" />

        <xs:attribute name="Dock"     type="DockType" use="optional" />

        <xs:attribute name="Padding" type="PaddingType" use="optional" />

        <xs:attribute name="Margin" type="PaddingType" use="optional" />

        <xs:attribute name="ReadOnly" type="ReadOnlyType" use="optional" />

        <xs:attribute name="MinimumSize" type="SizeType" use="optional" />

        <xs:attribute name="Name" type="NonBlankString" use="optional" />

        <xs:anyAttribute processContents="skip"/>

    </xs:complexType>

    <xs:complexType name="CustomControlOptionsType">

      <xs:sequence>

        <xs:any processContents="skip" minOccurs="0" maxOccurs="unbounded"/>

      </xs:sequence>

    </xs:complexType>

The CustomControlOptions is accessible to you control using IWorkItemControl.Properties[“innerxml”].

ReadOnly

Tells the control to display in read only mode.

BeforeUpdateDatasource/AfterUpdateDatasource

Implement and raise those events when before and after you flush user input to the datasource.

Clear

Clear the control content.

FlushToDatasource

Control is requested to flush any data to workitem object. This usually happens during save operation. In most cases data should be written to workitem immediately on user change.

InvalidateDatasource

Asks control to invalidate the contents and redraw. At this point, control can read from work item object and display/refresh data.

SetSite

Gives pointer to IServiceProvider if you intended to access DocumentService or other VS Services. If services are not needed, do nothing in this method.

We have added a new service in 2010 IWorkItemControlHost. Simply call serviceProvider.GetService(typeof(IWorkItemControlHost))). Here is the interface definition, might be useful to you if you want to interact with Microsoft Office:

    [Guid("c823b363-9cb6-4be4-baa3-bc4154409114")]

    public interface IWorkItemControlHost

    {

        void ShowWorkItem(WorkItem workItem);

        void ShowQueryResults(TfsTeamProjectCollection teamProjectCollection, string teamProjectName, string queryText);

        void SendToExcel(TfsTeamProjectCollection teamProjectCollection, string teamProjectName, List<string> fieldNames, List<int> workItemIds);

        void SendToProject(TfsTeamProjectCollection teamProjectCollection, string teamProjectName, List<string> fieldNames, List<int> workItemIds);

        void SendToMail(TfsTeamProjectCollection teamProjectCollection, string teamProjectName, List<string> fieldNames, List<int> workItemIds);

        bool SupportsSendToExcel { get; }

        bool SupportsSendToProject { get; }

        bool SupportsSendToMail { get; }

    }

IWorkItemToolTip

Implement this interface if you want the custom control’s Label to have a tooltip.

    public interface IWorkItemToolTip

    {

        ToolTip ToolTip { get; set; }

        Label Label { get; set; }

    }

When both the ToolTip and the Label are set, just call ToolTip.SetToolTip(Label, "This is a custom tool tip”). Well you probably want to make it useful, the standard control put the field reference name in the tooltip. You could also do something complicated such as showing the field history in the tooltip.

IWorkItemUserAction

Implement this if your control might require user action. user action required means the item is in a bad state and cannot be saved.

    public interface IWorkItemUserAction

    {

        string RequiredText { set; get; }

        Color HighlightBackColor { set; get; }

        Color HighlightForeColor { set; get; }

        bool UserActionRequired { get; }

        event EventHandler UserActionRequiredChanged;

    }

RequiredText: Friendly error message, will be displayed in the infobar in VS.

HighlightBackColor/ForeColor: use these colors in your control if a user action is required so its consistent with the rest of controls on the form.

UserActionRequired: tell them form if the control need input from the user

UserActionRequiredChanged: Raise this event if the UserActionRequired Property changes

IWorkItemClipboard

Implement this if you want your control to work with VisualStudio edit menu (Cut/Copy/Paste). Basically fire ClipboardStatusChanged if any of the Can* method might change.

    public interface IWorkItemClipboard

    {

        bool CanCut { get; }

        bool CanCopy { get; }

        bool CanPaste { get; }

        void Cut();

        void Copy();

        void Paste();

        event EventHandler ClipboardStatusChanged;

    }

Deployment

Adding the custom control to the form definition

To use the control in a form you will need to modify the form definition on the server. the easiest way to download a form you want to modify using the exportwitd command, modify it to use the custom control then upload the modified xml using importwitd. The tool to import/export work item definition is witadmin.exe (Run  “witadmin help importwitd “and “witadmin help exportwitd” to get help on using those commands). To specify custom control in the form simply locate the Form section in the type xml and modify or add a Control element. Here is an example of using a MultiValueControl from the codeplex project:

<Control Type="MultiValueControl" FieldName="Microsoft.VSTS.Common.Triage" Label="Triag&amp;e:" LabelPosition="Left" />

This is just like any other control definition, the syntax is the same, in fact, the import tool (for the most part) doesn’t distinguish between built-in control and a custom controls, it’s just a name for a control.

Deployment Folders

After you created a custom control (as part of a dll or an exe) you will need to drop both the dll and wicc file in one of the custom control folder both should be In the same folder unless the wicc file specifies a full path to the assembly.

Here are the locations that we look for custom controls in Visual Studio 2010. We search in this order. If one is found in one of these folders we will use it and not look further:

1.       All ValueNames under " HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\WorkItemTracking\WorkItemTracking\CustomControls\LookInFolders\". So if you want to store the .wicc and dll in some custom folder (eg c:\program files\MyTool\) you can, by adding this path as a value name under the above reg key.

2.       Environment.SpecialFolder.CommonApplicationData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\10.0\

3.       Environment.SpecialFolder.LocalApplicationData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\10.0\

4.       PrivateAssemblies Folder (eg C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies)

5.       Environment.SpecialFolder.CommonApplicationData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\

6.       Environment.SpecialFolder.LocalApplicationData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\

Location 5, and 6 is a fall back that VS2010, 2008 and 2005 look under for custom control so we recommend not using those folders to keep the 2008 or 2010 version of the control. Ideally if you have VS2008 and 2010 side by side, you should drop the custom controls for 2008 in one of these folders:

1.       Environment.SpecialFolder.CommonApplicationData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\9.0\

2.       Environment.SpecialFolder.LocalApplicationData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\9.0\

Wicc File

This file tell us where the custom control is. The filename is the name of the control. For example if in the XML the contorlType is specific as MultiValueControl, we will look for MultiValueControl.wicc file in the custom controls folders.

Here is a typical content of a .wicc file:

The xml file basically says which assembly (can be full path path) and the FullClassName of the custom control.

Making it easier

We made some changes in 2010 that makes working with custom controls easier. Keep in mind these changes only applies to VS 2010, we may remove support for these in the next version in favor for a more sophisticated mechanism.

In the control definition, you can specify a PreferredType that will be used instead of the standard type if was installed on the client. Say you have an IdentityControl that you like to use it for the AssignedTo field. Here is how you define specify that in the form xml:

<Control Type="FieldControl" PreferredType=”IdentityControl” FieldName="System.AssigedTo" Label="Assigned To” LabelPosition="Left" />

Again, if a client doesn’t have IdentityControl deployed it will fall back to using the standard FieldControl. VS2008 client will just ignore the PreferredType and use the Type instead.

We have found that this error happens when you are creating a team project collection, mostly commonly here:

• During initial configuration, with Advanced or Standard wizards
• When creating a new team project collection from the Team Foundation Administration Console

When does this error happen?

This error only occurs when Team Foundation Server, SharePoint Products, and SQL Server are all installed on the same machine and SQL Server has the TCP/IP protocol disabled.

The Trial and Developer editions of SQL Server will have TCP/IP disabled by default. We’ve seen customers running into this problem with customers trying to evaluate Team Foundation Server by using Trial/Developer editions of SQL Server.

What is the workaround?

The workaround is to simply enable the TCP/IP protocol for SQL Server.

NOTE: For more information on setting this, you can refer to the “How to: Verify SQL Server 2008” section of the Team Foundation Installation Guide.

Once this is complete, then you can create a team project collection using the Team Foundation Administration Console. The SharePoint site collection should be successfully created and you will have a fully operational system.

If you already have a team project collection with no SharePoint site created, then using the Team Foundation Administration Console, select that team project collection, and from the “SharePoint Products” tab, select to edit the default path. It will automatically prompt you to create a SharePoint site.

I’ve done this for 6 years. Each year, the class seems to be getting younger and younger, but I know its just me getting older. I’m 45, and most of the class looks 10-15 years younger than me.

I compare them to the way I was when I started out 20 years ago. I think it reflects a very healthy change in the industry.

• I followed orders. They think more creatively.
• I coded like heck. They use unit tests, code reviews, and in some cases, TDD.
• I went into a cave, and came out with code 2 months later. They have sprints, and demos, and daily stand-ups.
• I never thought of UI design. They are always thinking of it.
• I always underestimated the work. They still underestimate the work :-)

I think the software industry has come a long way. It’s good. It’s encouraging.

Here’s to looking forward to the future!

For example, let's say you have a tab on the work item form which manages your dependent features. It would make sense that the links control on that tab only display links to dependent features.

This is where the new filtering functionality with the links control comes in.

In the work item type XML in 2005/2008, this is what you did when you wanted to display a links control:

<Control Type="LinksControl"/>

With 2010, we’ve add the LinksControlOptions section to allow you to filter what link types to include. Of course, this is all documented on MSDN, but below is a summary.

The simple example would render a links control that includes all work item links (Related, Parent/Child), and exclude any non-work item links (ChangeSets, Hyperlinks, Test Results):

<Control Type="LinksControl" Name="UniqueName">

   <LinksControlOptions>

     <WorkItemLinkFilters FilterType="includeAll" />

     <ExternalLinkFilters FilterType="excludeAll" />

  </LinksControlOptions>

</Control>

The following example would render a links control that displays only Requirement and Hierarchy links.

<Control Type="LinksControl" Name="UniqueName">

  <LinksControlOptions>

<WorkItemLinkFilters FilterType="include">

<Filter LinkType="MyLinks.LinkTypes.Requirement" />

<Filter LinkType="System.LinkTypes.Hierarchy" />

</WorkItemLinkFilters>

<ExternalLinkFilters FilterType="excludeAll" />

 </LinksControlOptions>

</Control>

The following example would render a links control that displays all work item links except Requirement and Hierarchy links.

<Control Type="LinksControl" Name="UniqueName">

  <LinksControlOptions>

<WorkItemLinkFilters FilterType="exclude">

<Filter LinkType="MyLinks.LinkTypes.Requirement" />

<Filter LinkType="System.LinkTypes.Hierarchy" />

</WorkItemLinkFilters>

<ExternalLinkFilters FilterType="excludeAll" />

 </LinksControlOptions>

</Control>

The following example would render a links control that displays only Change Set links.

<Control Type="LinksControl" Name="UniqueName">

  <LinksControlOptions>

<WorkItemLinkFilters FilterType="excludeAll"/>

<ExternalLinkFilters FilterType="include" />

<Filter LinkType="Change Set" />

</ExternalLinkFilters>

 </LinksControlOptions>

</Control>

That should give you a pretty good idea of what can be done.

With TFS 2010, you can define multiple work item link types. This allows for you to customize link types to match your processes. This blog post is a primer in how to do that.

Quick-start guide on creating a new link type:

Here's how to create a new link type:

1. From the command shell, go to “Program Files\Microsoft Visual Studio 10.0\Common7\IDE”
2. Run "witadmin.exe exportlinktype /s ServerName /n System.LinkTypes.Dependency /f mylinktype.xml”
3. View the mylinktype.xml file that was created. It should look like this:

<?xml version="1.0" encoding="utf-8"?>

<LinkTypes>

<LinkType ReferenceName="System.LinkTypes.Dependency" ForwardName="Successor" ReverseName="Predecessor" Topology="Dependency" />

</LinkTypes>

1. Edit the mylinktype.xml file to look like this.

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyLink" ForwardName="My Successor" ReverseName="My Predecessor" Topology="Dependency" />

</LinkTypes>

1. Run “witadmin.exe importlinktype /s ServerName /f mylinktype.xml
2. Go to your Team Explorer and select “Refresh Cache”, or close and reopen your Visual Studio.

The new link item type should now be available to use from your forms.

What is that "topology" field for?

Now, what is that “topology” field in the definition XML. Topology assigns a set of rules that are enforced for that link type. There are four topologies to select from:

Network

Link types of this topology have essentially no rules and no directionality. You can have circular relationships, and the link looks the same from both sides.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyRelated" ForwardName="My Related" ReverseName="My Related" Topology="Network" />

</LinkTypes>

Directed Network

Link types of this topology are like Network links, except there is directionality. You can specify a name that appears at each end of the link. In other words, the link looks differently depending from which side you view it.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyDependent" ForwardName="My Dependent" ReverseName="My Provider" Topology="DirectedNetwork" />

</LinkTypes>

Dependency

Link types of this topology are like Directed Network links in that they have directionality, but an additional constraint to prevent circular relationships.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyPred" ForwardName="My Successor" ReverseName="My Predecessor" Topology="Dependency" />

</LinkTypes>

Tree

Link types of this topology are essentially trees, it enforces a one-to-many relationship and doesn’t allow circularity.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyTree" ForwardName="My Child" ReverseName="My Parent" Topology="Tree" />

</LinkTypes>

There you have it. Creating link types in less than 400 words.

The friendly name for some core fields have changed. They are:

There should be no implications for these name changes. These friendly names have always been available to be modified by the customer (using witfields in 2005/2008 versions, and witadmin in 2010 versions). All parts of TFS refer to the reference name, which remains unchanged.

There are a few exceptions to this:

• If you have existing team projects in a team project collection, and those team projects referred to the fields by the old friendly name, then any new new projects created on that team project collection will adopt the existing friendly name. We have special logic in the project creation that ignores changes to friendly names, and just adopts the existing friendly name.
• While the project creation process has special logic to ignore changes to friendly names, witadmin does not. So uploading any work item types via witadmin will fail.
• If you ever mark any of the above fields as reportable (none are reportable by default), and, you have one project collection with the old friendly name, and another project collection with the new friendly name, then the last project collection to synch to the warehouse will have a field name collision No data for that project collection will be synched to the warehouse until you resolve the field name conflict. This can be done using witadmin.
• If you mark the above fields as reportable, have resolved the name conflicts, and have written reports that reference the friendly name, rather than the reference name, then those reports will not work until you have updated them to refer to the new friendly name.

NOTE: If you need to resolve the naming conflict, you can either rename the field in the work item type definition to match the server's or change the server's name using witadmin changefield /name.

If you do nothing, you will probably be just fine.

However, if you are nervous, than after installing the RC or later build, then use witadmin to rename the fields to the new name, and update any process templates you are using that reference the old name. The MSF Agile/CMMI process templates have been updated to reflect the new name for versions RC or later.