TFS 2010 Work Item Tracking

In my last 2010 post, I covered Setup, Admin & Ops.  In this post I’m going to cover work item tracking features.  The truth, however, is that the lines between the next 3 posts are going to be pretty blurry.  I’ve tried to think about ways to partition it but Work Item Tracking, Project Management and Reporting are all heavily interrelated.  I considered writing a single post for them but then it would be 30 pages or something silly.  So, I’m going to break them up but bear with me on the rough edges.

Hierarchical work items

Perhaps the banner feature in TFS 2010 is the ability to break down work items into hierarchies.  The most common use for this is task decomposition – breaking high level tasks down into sub-tasks and those down into further sub-tasks, etc.  However, I expect people will get very creative with what they want to arrange hierarchically.  Prior to 2010, you can associate work items with “related” links and do some reporting around that but easily managing them as a hierarchy was not possible.  Here’s a screenshot of a totally hypothetical project I’ve made up.  Things to note…

• There’s a combo box at the top of the query editor called “Type of Query” and it is set to Tree of Work Items.
• The icon next to “Open Tasks” in the Team Explorer shows multiple indicate that this is a tree query.
• The results list shows the title indented following the hierarchy and allows for expanding and collapsing the results.
• You can’t see this, but rearranging your hierarchy is as simple as dragging and dropping one work item on another.

You can see right click menu items for the obvious things you’d like to do, add a new child, outdent, indent, etc.

Microsoft Excel integration has also been enhanced to support work item hierarchies as well…  As you can see, we use multiple “Title” columns to represent the hierarchy level in Excel.  You can also see some of the new Tree features in the ribbon.

And lastly, the hierarchy round trips with Microsoft Project as well…  As you can see here, Project can also be used as a roll up engine to compute rolled up schedule numbers.  In previous versions of TFS, the project hierarchy was only persisted in the MS Project file so TFS users couldn’t see the hierarchical relationships.

Custom link types

We have added the ability to define custom link types in TFS 2010.  In previous version there was really only one work item to work item link type called “related”.  Now you can define your own link types that can be used in querying and reporting (see more on querying in the next section).  As an example, as part of the new TFS base process templates, we’ve added a link type called Tests/Tested By.  It is defined to relate a test case and a user story and identifies the set of test cases for a user story.  However, you can define your own with whatever semantics you choose.

When you create a link type, you can define one of 4 link “topologies”:

• Network – Much like our existing “related” links.  Any two items can be connected and the link has the same name at both ends.
• Tree – A hierarchical link type that defines a “parent/child” relationship.  A parent can have many children but a child can only have one parent of a given tree link type.
• Dependency – A directed graph where links connect work items but there can’t be a cycle.
• Directed network – kind of a half way type between network and dependency.  There are no constraints on what or how many work items can be related but each end of the link has a unique name (e.g. Tests & Tested By)

Link Queries

Now that we have custom link types you can do some very cool stuff with traceability.  The reporting system always allowed you to report on links but now you can filter by link type and Team Explorer and Team System Web Access also enable querying on links.  So using the test case tests user story link I mentioned above, here’s a sample query in Team Explorer.  Notice that the Type of Query combo now says Work Items and Direct Links.  Also, notice that the query definition has a lot more filters.  Following the grid that selects User Stories, there’s another grid that selects how you want to filter what the matched user stories are linked to (Test Cases that are not closed, in this example).  In the linking filters you have 3 main options:

1. Return all top level work items – shows all work items that match the first grid control and then and matching linked work items.
2. Only return items that have the specified links – shows the same results minus any work items matching the first grid that have no related work items matching the second grid.
3. Only return items that do not have the specified links – shows only items that match the first grid but have no linked work items matching the second grid – for example, if I wanted to see user stories that had no test cases associated with them.

And finally, you can filter by one or more link types.  You can see by my query results that my sample project has 3 user stories, 2 of which each have one test case.

And, of course, all of this works in Web Access as well, but just to prove it, a picture is worth a thousand words…

New links control

Now that relationships between work items are playing a more first class role in the system it seems obvious you are going to want to do more with them on the work item form itself… enter the new work item form links control.  Here are the characteristics of it:

1. You can have as many links controls on your form as you like.
2. Each links control can be separately filtered.
3. The links control can be configured to pull fields from the target work item and render them in columns so you don’t have to open the target work items to see anything about it.
4. The “Add” button that adds new linked work items can be filtered to a set of link types to save mouse clicks.
5. The linked items can easily be opened in Excel.
6. And probably a few other things I’m forgetting.

So on with a screenshot.  Here’s an example of the Test Cases tab on a User Story work item.

Other new work item controls and improvements

There are a bunch of other work item control improvements in addition to the links control.  They include:

• HTML control – You can now have a work item control that renders HTML from a configured URL.  This is going to make it much easier to host external content in a work item form.  In some cases, it will replace the need to build custom work item controls.
• Link Labels – Labels on a work item form can now be configured to be clickable and will invoke a browser to display the results of an url.
• Edit controls - Edit controls now have adjacent toolbars that enable rich editing (fonts, colors, bold, italic, etc).  Edit controls will also now automatically convert a typed url into a clickable link.
• Labels – You can now have simple stand alone labels if you want to just put text on a form without an associated input field.

Field comparison queries

In previous versions of TFS, work item query clauses could only compare a field against a constant.  In 2010, they can now compare fields with each other.  So, for example, if I wanted to find all tasks where the Completed Work is greater than the Original Estimate, I could do this…  I suspect you’ll be able to think of lots of novel ways to use this.  We ran across the requirement when building our Project Server integration and try to find a way to easily identify work items where the project manager rejected cost changes made by the developer.

Group membership queries

It’s now possible to easily write queries that filter by groups of people.  TFS has always had the ability to synchronize with Active Directory to import group information.  Now you can write queries that enable you to easily filter by group membership.  For example, I could write a query to find all work assigned to “My team” like this…

Query Folders

The more powerful we make queries, the more of them you want to have – and that means you are going to need a way to organize them.  Also we’ve gotten a lot of feedback that people would like a better way to publish queries without having to be a Project Administrator (you have to be to save a Team Query in TFS 2008 and before).  We solved both problems with a new feature called query folders.  This allows you to organize your queries into folders both under My Queries and under Team Queries.  Further, under Team Queries, you can delegate permissions to the sub folders to whomever you like.  In the screenshot below you can see a query structure I’ve created a the security dialog where I’ve granted the Contributors group permission to contribute queries to the Web Team folder.  I know this is going to be a VERY popular feature internally where we get dozens, if not hundreds, of queries people want to share.

Usability improvements

We’ve made a number of small work item tracking usability improvements.  I don’t think I can even remember them all but I’ll mention a few.

We’ve added several controls to improve your options for managing layout for your work item tracking windows.  Looking at this screenshot, you will see 4 small controls on the right hand side of the splitter bar between the results list and the work item form.  The first two switch back and forth between a horizontal split and a vertical split.

like this…

The second two make it simple to “maximize” either the work item form or the results list, like…

or this…

Further, you’ll notice the new Next and Previous buttons – makes navigating through the list of work items possible when looking at a maximized work item form as in the last screenshot.

Another nice enhancement is the ability to drag an email message from Outlook into the work item attachments list and automatically attach the .msg file for tracking email conversations along with work items.

WIT Categories

We've heard a lot of feedback on the difficulty of making our reports work and writing new reports in the face of significant work item tracking customization.  One of the features we have added to simplify this is something called "Categories".  You can mark work item types as being in a Category and then write your reports against the category rather than the work item type name.  This is particularly useful as you classify work with increasing precision.  For example, you might have separate User Story and Quality of Service requirement work item types.  They have different data models for a reason but you want to easily write reports against all "requirements".  You can tag them with the same Category and write reports against that.  Then the report will pick up both work item types.  This also enables you to rename work item types, etc and still have tools work by referring to the category.

Conclusion

Whew, OK, that’s it for work item tracking.  It’s a lot of stuff and there’s a lot more left for me to talk about.  Once you get Beta 1, you can start to play with all of this and I’m eager to hear your feedback.

Brian