Store additional data with a link between 2 work items

Question

We use some custom link types in our process template to meet some regulatory requirements around traceability.

For instance we use a custom WIT called "Release" and as bugs are filed and triaged they are associated with one or more releases by a custom link type (To facilitate reporting).

What we are finding ourselves wanting to do is store additional data with the link between the two work items. Information like Is the bug to be fixed for a release it affects and if not why not. It would also help to be able to identify a target build for verification of the fix in the release and I am sure one or two other items will pop up.

The only way I can currently figure out how to do this is with a Shim type of WIT that will have a link to the bug and a link to the release. This is less than desirable for a number of reasons, but unless I am missing something it is looking like the only option without some serious plumbing.

I did find this blog post:

http://blogs.msdn.com/b/narend/archive/2006/10/13/how-to-extend-linking-and-workitem-ui-with-custom-link-types.aspx

but am not sure if it is the right choice. I would prefer to avoid custom controls due to the install / maintenance and the impending release of VS11.

So any ideas on this one, or am I out of luck?

Answer 1

If you're using Team Build, use all the traceability available in TFS and generate your release notes from the Data Warehouse, tehn you won't need to store these details in a Release Work item. There are "Found in" and "Integrated In" items in the standard bug workitem which help you figure out which bugs can be verified in which builds and you can use the "Build Quality" to track whether a build was used for a specific release.

So you might be able to accomplish what you want by linking a Build to your release item and derive the bugs, fixes, known issues etc from there. You'd then have to use Reporting to generate the actual release notes.

---

My blog: blog.jessehouwing.nl

Answer 2

Hi Bill,

How about the issue now?

If anything is unclear, please free feel to let me know.

Best Regards,

---

Lily Wu [MSFT]
MSDN Community Support | Feedback to us

Answer 3

Thanks for the suggestion Jesse.

Unless I am missing something, that is basically what we are doing now (sans Build Quality), but I am sure we could be doing it better. First with the Integrated In field If I have three minor releases integrating changes to address the same bug, across three separate builds we are finding we have to track multiple bugs (one for each minor) to determine when the bug has been integrated. In addition and more important, we are left with no record of a decision to NOT fix a bug. If we don't fix it there is no build on which it was integrated etc. This is getting a little involved trying to relate the separate bugs and produce a clear trace matrix.

I'm sure this type of request is received about as frequently as requests for electronic signatures in the testing tools, so I wasn't really expecting a clear path here, especially since all of my Googling came up empty.

However, if someone could speak to the blog post linked to in my original post. In the blog entry there is a screen shot of a custom link dialog and along with the item picker and the comments field there is a "Custom Product" Field. My guess is this field on the dialog is for help in selecting items from the picker and its value is not retained with the created custom link, but would like to verify that. If it is retained with the link it may be a path forward.

Thanks,

Bill

Answer 4

I wrote that blog post many years back (2006). I moved out of TFS team and I do not remember clearly how it works. However, we implemented a much better linking functionality post that VS 2005 release and I think you can acheive your tracking goal by using custom linking in current TFS version.

To answer your specific question on Custom Product field, yes, I remember that that field is for helping workitempicker and not for retaining that info in the link.

Naren

---

http://blogs.msdn.com/narend

Answer 5

Thanks Naren, I appreciate your time.

Regards,

Bill