January | 2014 | Simplifying Complication

We have come from originally a TFS 2008 CMMI Work Item Template and have upgrade through 2010 and 2012. When we upgraded to TFS 2013 we were keen to use the Agile Portfolio Management features. After enabling it we ended up with the categories Features and Requirements. These categories names we find are often use interchangeably so having them mean distinctly different things was confusing.

By default if you are the Scrum template you get something far less confusing, Features and Backlog items. Initiatives can be added following Agile Portfolio Management: Using TFS to support backlogs across multiple teams guide.

So when it came to use agile portfolio management the hierarchy is was not clear. Fortunately this is easily fixed. I assume the TFS Team did not what to end up with another area like Team Projects that is not able to be renamed. To begin open the Developer Command Prompt which has the paths configured for witadmin.

The examples I have done below have been done on the Visual Studio 2013 ALM Virtual Machine provided by Brian Keller. I recommend anyone who is a TFS Admin have the appropriate Visual Studio ALM Virtual Machines for testing changes on. Especially if you are managing a small team since you are unlikely to have a staging environment and setting one up is too much work. Consider these staging and test environments. With the error I got below no one was effected while I worked out the solution.

Renaming Categories

Export the process configuration definition to an xml file:

witadmin exportprocessconfig /collection:http://vsalm:8080/tfs/FabrikamFiberCollection /p:FabrikamFiber /f:%userprofile%\desktop\ProcessConfiguration.xml

Modify the export xml setting the name to something more appropriate:

<!-- Feature to Saga -->
<PortfolioBacklog category="Microsoft.FeatureCategory" pluralName="Features" singularName="Feature">
<PortfolioBacklog category="Microsoft.FeatureCategory" pluralName="Sagas" singularName="Saga">

<!-- Backlog Item to Journey -->
<RequirementBacklog category="Microsoft.RequirementCategory" parent="Microsoft.FeatureCategory" pluralName="Backlog items" singularName="Product Backlog Item">
<RequirementBacklog category="Microsoft.RequirementCategory" parent="Microsoft.FeatureCategory" pluralName="Journeys" singularName="Journey">

<!-- Task to Quest -->
<TaskBacklog category="Microsoft.TaskCategory" parent="Microsoft.RequirementCategory" pluralName="Tasks" singularName="Task">
<TaskBacklog category="Microsoft.TaskCategory" parent="Microsoft.RequirementCategory" pluralName="Quests" singularName="Quest">

Import the process configuration definition file:

witadmin importprocessconfig /collection:http://vsalm:8080/tfs/FabrikamFiberCollection /p:FabrikamFiber /f:%userprofile%\desktop\ProcessConfiguration.xml

Refreshing the browser after renaming the categories, my URL is wrong since the category no longer exists but I get this very good message:

After messing with the process configuration and then getting an error message containing the line, “Don’t worry, the system is not broken”, is very comforting.

Renaming Work Item Types

This is appears easy with just one command.

Rename Feature to Saga:

witadmin renamewitd /collection:http://vsalm:8080/tfs/FabrikamFiberCollection /p:FabrikamFiber /n:Feature /new:Saga

A confirmation prompt appears:

Are you sure you want to rename the work item type Task to the new name of Quest? (Yes/No)

Rename Task to Quest:

witadmin renamewitd /collection:http://vsalm:8080/tfs/FabrikamFiberCollection /p:FabrikamFiber /n:Task /new:Quest

However after doing this you may get this nasty error message when viewing the backlog essentially telling you this time your system is broken and not really useful information on how to fix it:

If you export and then import the process configuration definition it will tell you a reason why this could be.

Correcting this color reference in the xml as such however gives you this error.

<!-- Update Task to Quest for the new work item type name -->
<WorkItemColor primary="FFF2CB1D" secondary="FFF6F5D2" name="Task" />
<WorkItemColor primary="FFF2CB1D" secondary="FFF6F5D2" name="Quest" />

Regardless neither of them are the error. This issue is an application pool recycle of TFS is required. After the application pool recycle, the backlog will be working again.

Now you can upload your modified process configuration definition correcting the work item colors.

Result

Now I have a much more interesting hierarchy:

Technorati Tags: Team Foundation Server

Here we have this nice obscure error message from Visual Studio 2013. I get it for almost all my projects within the solution, which at 23 or 67 that’s no fun.

If a project is reloading due to a background update and you click Reload, then you might get this other unhelpful message.

The strange part is that it would go away and then come back. What we discovered is that it is a bug due to the source control bindings on the solution mismatching the connection settings in Team Explorer. In our case we have multiple URLs that resolve to our TFS server. In our solution file we have http://tfs:8080/tfs/<projectcollection> yet in my connection I have https://tfs.<domain>.com/tfs/<projectcollection>. After going through all the error dialogs if you Save All to save the solution file and do a diff, you will see all the URLs updated to your connection.

After making sure all the source control paths are the same in all your solution files, ensure everyone on the team updates their TFS connection, by creating a new connection to the desired address.