Hidden Gems in TFS 2012–Part 8 Related Work Items in a Build Report

In this series of blog posts I like to highlight some features of TFS/Visual Studio that people seem to overlook. In my day to day job I often see that people don’t know about certain feature that are available in Team Foundation Server, Visual Studio or some of the Powertools.

Some features are available as a Powertool. These can be downloaded from here

Earlier Posts

• Hidden Gems in TFS – Part 1 Annotate
• Hidden Gems in TFS – Part 2 Work Item State Diagrams
• Hidden Gems in TFS – Part 3 Editing multiple work items at the same time (Bulk Edit)
• Hidden Gems in TFS – Part 4 Finding status in Source Control
• Hidden Gems in TFS – Part 5 Handling alerts and notifications
• Hidden Gems in TFS – Part 6 Managing workspaces in TFS with Workspace templates
• Hidden Gems in TFS–Part 7 Searching and Finding Work Items in Team Foundation Server

In this part……

Related Work Items in the Build Report

I discovered this Hidden Gem recently because I overlooked it. In TFS 2010 and older there was already the great feature that the build report showed all related work items. When you related a work item to your check-in, the build server automatically picked that up and displayed it.

A much heard complaint was that only the items that you related with the code were displayed. This seems logical, but many users worked on tasks, but wanted the Build report to show the parent Bug or Requirement (PBI). To achieve this, they would have to check in the parent as well. Also, the work item links were forgotten at check-in, because it happened after doing the actual work.

In 2012 things have changed. TFS 2012 is more task-centric. This means that you normally will not check-in code against a bug or PBI but against a task, and you will relate work items before you start working on the code instead of afterwards.

Let me illustrate with a small example.

Lets say I have created a Bug and assigned it to myself

When I look in the Team Explorer in the “My Work” section, the bug does not show.

This is because the default setting of “My Work” only displays tasks. Read my post about changing the available work items query here.

Add a task to the Bug and it shows nicely in the Available Work Items

You can drag this to “In Progress work” and start your work.

When you are done with fixing code, Check in on the Pending Changes Tab. You will see that your Task is automatically related.

Now start a build, that builds this change.

If you now look at the build report, you see that not only the task where you worked on is related, but also the parent Bug! This is a great improvement and very useful in traceability scenarios!

Hope this helps !