Skip to main content

HOW-TO: Add/edit a field in Team Foundation Server 2012 using Visual Studio 2012

It's been a while since I made a purely technical post...

So, today I wanted to make a change to a Microsoft Team Foundation Server 2012 (TFS2012) instance that I am working with to reflect "Actual" time spent on a task - mainly for reporting purposes, and because I have found in the past that making this minor process adjustment yields a relatively useful metric over the long-term.

I am using the Microsoft Scrum 2.1 Process Template ( for a project that I am working with. So that I don't forget how to do this (again!) I will blog-post the procedure I've used to add this field to the template as a screen-shot-based tutorial, as follows...


Assuming you are familiar with the Scrum Process Template (2.1-ish) - open a task and take a look at the "Details" section, as follows:

 This is where I want my "Actual" field to show up.

Get the Power Tools

Download and install the latest version of the Microsoft Visual Studio Team Foundation Server 2012 Power Tools:

Open Work Item Type

You need the Power Tools to see this menu item:

Select the "Task" type

Make a "New " field

Set the field up as being a "Measure" that shows up in reports - if it doesn't show up in reports, frankly it's probably not going to be of much use (and most likely a hinderance).

Give the field a Field Reference name that makes sent to you and your colleagues - ideally, use the standard .NET namespace practice for your company.

If you want to jazz things up a bit or add a different type of field, you can get an idea how best to set the field up by looking at the configuration of other similarly typed fields - double click or "Edit" them to open and view.

Add the field to the UI

Associate the UI with the new field

Find the Field Reference in the DDL for the Field Name that you want to use in the UI.

Again, you can get an idea as best to set this up by looking at the configuration of other similarly typed fields in the UI hierarchy.

Save it...

After (Success!)

Open your task again and you should now find that there is an "Actual" field there, as above, ready to be used! You might need to refresh your browser before it shows.

For reporting purposes - you should also see that the "Actual" field shows up when you go to run a query now, or at least is available to be selected and reported on - as per the above image, showing the Query Editor.


Couple of caveats - this tutorial shows how to make the change directly at the server; to be safe, you might want to download the template and edit it locally, then upload it back to your TFS server. As I mentioned earlier, adding a field like this is not much use if it doesn't show up in reporting - worth reiterating.

TFS2012 (and TFS2010) Power Tools enable you to edit a range of features of the Scrum - and any other - Process Templates, including the actual associated workflow. That does not mean to say that it's a good idea to do that willy-nilly. 

These templates are the way they are because they represent the most flexible, and close to best-practice approach that the developers could get to. Any modifications you make will likely be diverting the process away from what's considered best-practice - certainly as far as Scrum is concerned for example, there's nothing in Scrum that requires the tracking of "Actual" time spent...

The "official" Scrum Guide:


Popular posts from this blog

HOW-TO: Apply a “baseless merge” in Team Foundation Server 2010 (and 2012)

Another purely technical post on TFS...
The scenario We wish to migrate code between branches that do not have a branch/merge relationship, in order to expedite urgent changes being made by a project team, without disrupting on-going BAU development work. Sample branch hierachy/strategy Imagine the following branching strategy in TFS (visible by connecting to TFS via Visual Studio 2010 or 2012):

Essentially you have a "DEV" branch, which has a "QA" branch, which in turn has a "PROD" branch. DEV is the branch that you would be using for BAU development. As a piece of development matures, you move it into QA, where it is tested by your internal QA team. There may be further changes made in DEV that are moved into the QA branch as the QA team pick up issues. Once the QA team are happy with a packaged of changes, they will move them into PROD, which is essentially the hand-over to the customer. The PROD branch represents the software that the customer has.


Eclipse/Android error: "Multiple dex files define [...]"

Wow, I am really going nuts blogging this-evening - 2nd post in less than an hour. 

Anyway this is a particularly nasty error that I keep running into with Eclipse/Android when starting the emulator after I have not run it for a little while. Since I run the risk of permanently forgetting the solution to the problem every time I walk away from my Android project (and thus having to spend a painful hour-or-so digging up the procedure again), I will blog it here, for my benefit, and for the benefit of anyone who may also suffer the same problem.

The gist is that when you start the emulator in debug mode (that is, you hit the button in the following image), you get the following error message come out on the console and a nasty popup telling you nothing more than there is an error with your program and you need to fix it:

[2012-04-06 23:20:57 - Dex Loader] Unable to execute dex: Multiple dex files define Lcom/google/gson/ExclusionStrategy;
[2012-04-06 23:20:57 - SimpleList] Conversion to Dal…