What do the various link types in Rational Team Concert mean?

In an RTC work item, on the links tab, you'll notice several types of links you can create. When getting started with RTC, its difficult to know what link type to create.  If the project area you are using is a LifeCycle project linked to an RQM and DNG project, you'll find even more link types that may make your head spin.

Basic Work Item Links For Just RTC

Let's get started with the basics. These links are used only in RTC, and do not link into the other CLM tools like DNG for requirements management or RQM for test management. 

The first is the Add Related link.
This is the general purpose links two work items. This linkage type has no real context. It does not tell you why the two are linked. Is there a dependency between the two? Is one blocking another? Parent/child? Nope - no context. This is the link type you get when you mention a work item in a comment or description area of another work item.

Next is the Add Related Artifacts link.

This one allows you to link to external content, such as Wiki's, sharepoint content, Connections content, deployed URL's and such. This should ONLY be used for external content, not for URL links to other work items. 

The one link you might rarely, if ever, use is the the SVN Revisions link.

This is for subversion code revisions. However, your organization may have most likely converted source from subversion (SVN), to RTC. If they have not, they should as RTC source code management is far superior than SVN. 

Directional Links in RTC

You'll notice that many of the links appear in what looks like pairs. This is for a reason. These links are directional. Do you remember diagramming sentences in high school? Finally, here is where you get to use that knowledge! These linkage types provide context as to why the two are linked. For example, take the linkage pair Blocks / Depends on. These are reciprocal. 

If you specify that Task 1 blocks Task 2, then on Task 2, we should see the link as "Depends On". Looking at this in the following diagram helps us to understand how to read the two in a sentence:

Directional relationship between RTC work item links

In this case, task 1 "blocks" us from working on or making progress on task 2. For example, let's say task 1 is to Install WebSphere Liberty on Staging Server. Task 2 is Configure Java EE  security on the Staging Server. Obviously, we cannot edit the security configuration on the Liberty server if it has not been installed. This particular linkage type is what the built in work item query "Blocked Work Items" looks for. A project manager or Scrum master can see this view and will be able to better help the team prioritize work and remove obstacles to productivity.

If you understand this pairing of link types, then the rest become a bit more obvious. 

The Resolves/Resolved By is commonly used on defects, where if you fix one defect, it effectively resolves another defect. This one is rarely used on anything but Defect work items. 

The Duplicated By / Duplicate Of pair, indicate that one task or defect is an exact duplicate of another. This type of link is common when two different people have entered the same defect (perhaps worded slightly different). In this scenario, simply choose one as the duplicate. When one defect is marked as resolved, RTC will mark the duplicate resolved as well. 

Lastly, we have the parent/child link types. These are special in that a work item can only have one parent (did you know work items were asexual?).  A work item, however, can have multiple children. Child work items, in turn can have children, and so on. These also have special behavior properties in RTC, such that the RTC Project Administration (or JazzAdmin), can restrict the parent work item from being closed until all the children have also been closed. This is typically a good practice to have, especially for Stories with multiple tasks. A Story should not be closed until all the children have been completed. 

Planning Links

The next group of links that are specific to RTC, are those that affect project planning. This means that work items with these link types will affect project plans and reports. 

Let's start with the Affects Plan Item link type. This is typically used on a defect, to indicate that if affects a story or epic. Stories and Epics are plan items, whereas tasks and defects are execution items. A plan item is the when part of a requirement, as in "when is the requirement going to be implemented". The execution items are the "how do we implement the requirement". Plan items are measured in story points, whereas execution items are measured in hours.  This link type is the reciprocal link type as Affected By Defect link type. This really should only be put on a story or epic to indicate that it is affected by a defect, and on the linked defect, it would have the Affects Plan Item link.

Next is the Contributes To and Tracks link types. This are linkages between cross-project plans, and allows you to have a work item track another Plan item in another plan or project area. The Contributes To allows you to indicate that a given work item (such as a task), contributes effort to another Plan item. That plan item may be in the current project, or in another project. For example, if you have two project areas, for two very different software projects, and there is a task to install infrastructure that both projects will be running on, we can say that the task "Contributes To" the stories in both project areas. This will allow the work item to show up in project plans in both project areas. 

Formal Training for RTC

If you've been slogging around trying to learn RTC on your own, we recommend that you get some formal instruction on the product by a knowledgeable vendor who actually works with the product in the field. 

Find out about RTC Training