Inside VSTS

Relating Work Items to Each Other

Deciding how work items should relate to each other can be tricky, depending on which version of TFS -- 2008 or 2010 -- you're working with. Jeff guides you through the potential pitfalls.

• By Jeff Levinson
• 06/09/2009

I'm often asked how work items should relate to each other. It seems like a simple question but the answer is often pretty complicated.

This is a much larger issue in Team Foundation Server (TFS) 2008 than in TFS 2010. TFS 2008 doesn't have the benefit of hierarchical work items -- but even with that benefit, the structure of your work items is important and very difficult to fix later. So what's the best way to do this?

For this article, I'm going to look at the MSF for CMMI/Process Improvement template. Why am I leaving out the Agile template? It's much simpler; there's no Change Request, which adds some additional complications. For the purposes of this discussion, assume that a Scenario (in the Agile template) is equivalent to a Requirement (in the CMMI template).

The Requirement is always the top-level item when looking at the work item hierarchy, in both 2008 and 2010. This work item lays out what the feature is supposed to do -- and even this causes a problem, in my opinion (more on that in a moment). The Requirement is a business objective that users can understand. Tasks are children of Requirements. The Task represents an artificial list of things the developer must do to complete the Requirement. They're there to do two things: provide a way for developers to break down the Requirement into manageable tasks and allow teams to track progress against a Requirement.

In TFS 2008, this relationship is even more critical because you can't query past one link without a great deal of difficulty. To illustrate this point, image that you have a Requirement related to a Task which is related to another Task. You can't easily determine in a report that the requirement is composed of two tasks.

And this brings me to the problem I alluded to earlier with Requirements in TFS 2008.

Take the case of a Requirement, which is a Use Case. A Use Case is composed of a Normal Path and 0 - n Alternate Paths and Exception Paths. Except a Use Case is too big to really estimate and code. A logical breakdown would be each path in the Use Case is a separate Requirement -- and it is, since by definition a feature works once the Normal Path is implemented. The Alternate and Exception paths are modifications of an existing feature. Therefore, the major Requirement might be a Use Case with sub-Requirements (for each path) related to this major Requirement.

This makes running reports very difficult to track status. Remember to take this into account when creating your hierarchy. In TFS 2010, this is less of a problem because the Parent/Child Link Type tells us what the parent is and what the child is.

Now, let's continue. Change Requests should only be related to Requirements. There are no Change Requests for Tasks as Tasks are, by default, not something a business user would have visibility or understanding of. However, a Change Request can be related to multiple Requirements (especially if the Change Request is related to base functionality in an application). Be aware that this creates its own problems with reporting because the Change Request can be double-counted.

Bugs also should only be related to Requirements (with one exception) because the Requirement doesn't work and that's what the user cares about. Here's the exception: when you're using a Test Case Work Item Type. In 2010, this is built-in. In 2008, we recommend that customers create a custom Test Case WIT. In this case, a bug may be related to a Test Case -- in fact, we hope it is because that means you discovered the bug through a solid testing process -- and a Requirement. This also can lead to the problem of double-counting in reports.

Tasks may be related to Change Requests because it requires a breakdown of work that was started by a Change Request (and you want to know what a Change Request took to implement).

Figure 1

This simple relationship is shown in Figure 1 above. Knowing this, you can easily visualize the Requirements tree and the relationship of code to a Requirement.