When you work a lot with teams that start to use Team Foundation Server you will most certainly run into teams that already have some, or even a lot of, experience with Team Foundation Server. Now these kind teams are both a blessing and curse, you don’t have to teach them a lot about working with Team Foundation Server, but they will usually already have carved out a process, picked a process template and sometimes did some (or a lot) of customizations on it to make it just right for the way they want to use the system.

Now this is perfectly fine but if you work in an enterprise environment you might not want each and every team to have their own flavor of the process template. This might cause you to have a lot of work during an upgrade as I found out myself doing a TFS2010 to TFS2012 upgrade a while back.

So where do you start when you want to move all your teams to the same process template? You could argue that there is not “one size fits all” so why would you want to try and consolidate every team into the same template, I feel one of the main reasons here is maintainability. And if you look at for instance Visual Studio online, where you don’t get to customize the process template, a generic enough template might just be your “one size fits all”. I was asked myself a few weeks back to map the process templates of 3 different teams, which had customized them quite a bit, back to our so called “base template”,

Team Foundations Server’s historical records are your friend!

The mapping I had to do contained 3 different project with a total of about 20.000 individual work items and months if not years of history. So where do you start comparing 20.000 work items to the types you have in your own process template. It seems quite a monolithic task but since you are working with a system like Team Foundation Server there is a wealth of information and history in the databases. So the first thing you might want to do (I know I did) is find out which work item types are used an how many there are. You can do this using Excel’s Power Pivot features to connect to Team Foundation Servers Data Warehouse and extract the work item count per work item type for a single project and turn it into a chart like the one below:

This will give you insight into the actual work item type usage, and what to actually focus on for the next part of the mapping. If for instance 5000 User Story work items exist and only 100 Task work items that might mean that Task work items aren’t really used and thus will not be that important to map, User Story work items will be important to map. Now you can also extend your Power Pivot view to include the “Created Date” or the “Changed Date” of a work item and create a Stacked Area graph that shows work item usage or creation over time, this will give you a bit more insight into what types are used heavily in the past few weeks or months.

Some work item types might contain a lot of fields on the form, but how do you know whether these field carry any importance for the team, how to you know that these fields are even used if you have to investigate 20.000 work items? What I found a really powerful view to render is how many of the fields were not empty or did not contain the default value, this will most likely greatly reduce the number of fields you will have to discuss.

Below a simple sample of such a graph:

It is not straightforward to get this kind of information out of Team Foundation Server, you could do it using a SQL query on the warehouse database, but that does not contain all fields (only the reportable ones). So also using Excel Power Pivot will not give you a 100% view. You could run work item queries, select all fields, export it to Excel and using formula’s extract the data, but this is quite labor intensive and your a quick to make a mistake with such vast amounts of data. So what I did myself was create a simple C# application that uses the Team Foundation Server Client Object Model to get the work item data out of the system. The tool basically queries for all work items and for each work item type all empty and non empty fields are counted (default values for fields are also counted as empty). I had the tool ignore the so called “Core Fields” because these are mandatory to have on a Work Item Type so you can always do a one on one mapping for those. This information is exported to a CSV file for each work item type which you can simply import into Excel. The great thing is that once I had this tool, it was real easy to run it again and again (and again) against different team projects.

Now this is no magic pill making all the discussions go away, but it is a tool to at least make sure you are discussing the right things, simply put, how important can a field be if it is almost never filled in?

The sources are available on our Info Support GitHub page (link), To use the application you will have to modify the Program.cs file to connect to your own team project, it will export a .CSV file per work item type into the working directory:

static void Main(string[] args)
{
	string teamProjectCollectionUrl = "https://your_server/tfs/your_collection";
	string teamProject = "your project";

	Uri teamProjectCollectionUri = new Uri(teamProjectCollectionUrl);

	IEnumerable<WorkItemTypeData> workItemTypesData = WorkItemAnalyzer.Analyze(teamProjectCollectionUri, teamProject);

	WorkItemTypeDataCsvExporter.Export(workItemTypesData);

	Console.WriteLine("Press any key to exit...");
	Console.ReadKey();
}

Share this