Handling Change Requests in Three Tier Hierarchy for MSF Agile 5.0

In this short post, I will discuss two models for handling change requests in the MSF Agile 5.0 process template for Team Foundation Server 2010. If you’re wondering “What Change Request?” since out of the box the MSF Agile 5.0 template doesn’t have one, then it is the Change Request that I added in the three tier hierarchy process template I discussed from my previous blog here. Fundamentally, the question is that once we have added a Change Request work item to the MSF Agile template, how do we handle its relationship to other work items in the hierarchy? There are a couple of models I would propose, though I do have a preference for one over the other. So here is the first model below, which places a Change Request as a peer of the Capabilities it affects, along with the same relationship to the Tasks it affects.

One great thing about TFS 2010 hierarchical work items is the panoply of available link types between work items, which can be directional or non-directional. In this case, when I create the Change Request, I use the directional Affects link type when linking to both the Capability and Task level. When you open the Change Request and look at its links, you will see a heading for Affects with the corresponding links, and when you open a Capability or Task that is affected by a Change Request, you will see a heading for Affected By with links to the corresponding Change Request(s). Now that is coolness.

Another viable model would be to continue to treat Change Requests and Capabilities as peers, but create new Tasks as children under the Change Request in order to cleanly segregate what Tasks are specific to the Change Request. You can see this model below, which could also include links to existing Tasks affected by the Change Request, but continue to have child relationships with their respective Capabilities.

So what are the “pros and cons” of each model? In the first model, we won’t know explicitly what Tasks are related to the Change Request, as there will be Tasks that exist prior to creation of the Change Request, and also Tasks that may also be created as a result of the Change Request. In the second model, we know explicitly what Tasks were generated as a result of the generation of the Change Request.

The problem with the second model, which demonstrates my preference for the first model, is with queries as well as reports. In the first model, we have a clean Feature – Capability – Task hierarchy, with the Change Requests only informative and incidental to the hierarchy. Like any other work item, we can track open Change Requests through queries, even though they won’t show up on the out of box reports. The advantage is that the Tasks, which are children to their respective Capabilities, will continue to show up in reporting, which fully supports our three-tier hierarchy that will be regularly queried by developers. So I favor the first model over the second for the reason of accurate hierarchical queries, as well as reporting. Let me know what you think.

Comments

• Anonymous
  January 16, 2011
  I would favor the second one, as it is more pure. Moreover, I would consider all the initial work on a feature or capability as a change as well. So, you would get a capability linked to one or more change requests and/or bugs. These change requests and bugs are linked to the tasks. BTW: Do you know why change requests are not included in the Agile 5.0 template?