Choosing Link Types to Effectively Track Your Project

When you create relationships between work items, you select the type of link that best supports your project planning and tracking efforts. Different types of links support different capabilities and are based on one of four topologies, as described in Working with Link Types.

Topic Contents:

Review the following sections to determine the best choice of link type to support your tracking needs:

• Use a Related Link to Make Non-Hierarchical Relationships

• Use Parent-Child Links to View Multi-Tiered, Hierarchical Relationships

• Use Predecessor-Successor Links to Plan and Track Project Tasks and their Dependencies

• Use Dependent Links to View and Track Dependent Work Items

• Use Changeset and Versioned Item Links to Associate Tasks and Features with Development Work and Version Items

Use a Related Link to Make Non-Hierarchical Relationships

To create the simplest relationship between work items, add a related link to a work item. This type of link has no inherent hierarchy and is based on the network link topology. You can use the related link type to relate work items that are at the same level, such as two user stories that define features that overlap one another. Or, you may want to create a related link relationship between two different work item types that are defined in two different team projects and managed by different teams.

With related links you can meet the following goals:

• Find and view work items and their related work items in a two-tiered view. For more information, see View and Modify Work Items in a Direct Links View.

• Create simple relationships with few restrictions.

Use Parent-Child Links to View Multi-Tiered, Hierarchical Relationships

You create parent-child links between work items in order to view multi-tiered, hierarchical relationships between the work items. This link type is most often used to break down user stories into features and to divide tasks into subtasks. Parent-child links are based on the tree topology, support a one-to-many relationship set, and prohibit circular definitions, that is, a child node can only have one parent.

• Outdenting, indenting, and performing a drag and drop operation on work items. For more information, see View and Modify Work Items in a Tree View.

• Export selected work items from tree query results, and add and modify work items and their links using Office Excel. For more information, see Configure Work Items in a Tree List in Office Excel.

• Create a top-down break down of work items in Office Excel. For more information, see Performing Top-Down Planning Using a Tree List of Work Items (In Excel).

• Maintain task summary relationships in both Office Project and Team Foundation Server. Parent-child links are created for summary tasks and their subordinate tasks.

• Generate reports that can be updated or refreshed from a work item tree query. For more information, see Flat Lists and Tree Lists, Query Lists and Input Lists.

When you define parent-child links, note the following restrictions and recommendations:

• A work item can have only one parent, although a parent work item can have many children.

• Work items joined by parent-child links must be defined for the same team project. This action is recommended if you plan to use Office Excel or Office Project to modify or update work item data.

  Note

  You can create parent-child links between work items that are defined in different projects. However, if you export a query to Office Excel or Office Project, only those work items that are defined for the team project for which the query is defined are imported into the Office client.

Use Predecessor-Successor Links to Plan and Track Project Tasks and their Dependencies

If you use Office Project to plan and track projects, and you link two tasks that represent work items, when you publish the data, Team Foundation automatically creates predecessor-successor links between the work items. Predecessor-successor links are used to track tasks that must be completed before others can be started. Predecessor-successor links are based on a dependency topology, support one-to-many relationships, and do not allow circular definitions.

You can perform one or more of the following tasks when you connect work items using predecessor-successor links:

• Create a project plan, make and track changes by using Office Project, and publish the work items as tasks to Team Foundation Server. For more information, see Create a Microsoft Project Plan from Team Foundation Work Items.

• Find and view predecessor work items and their successor work items in a two-tiered view. You can also modify the link relationships by using the drag and drop operation. For more information, see View and Modify Work Items in a Direct Links View.

When you define predecessor-successor links, note the following restrictions and recommendations:

• Do not create links that define circular relationships. If you attempt to create or publish work items that form cyclical links, you will receive an error that directs you to resolve them before you can publish.

• Create predecessor-successor links only to work items that are within the same team project (recommended).

  Note

  You can create predecessor-successor links between work items that are defined in different projects. However, if you export a query to Office Excel or Office Project, only those work items that are defined for the team project for which the query is defined are imported into the Office client.

For more information about link types and Office Project, see Quick Tips and Operational Differences when Tracking Tasks Using Microsoft Project and Team Foundation.

Use Dependent Links to View and Track Dependent Work Items

You create links to work items by using a dependent link type in order to track work items that impact the ability to complete a requirement, feature, or task. Also, you can create links to work items that cross project boundaries. For example, the Microsoft Solutions Framework (MSF) for Agile Software Development v5.0 process template provides the following additional dependent link types: Tested By/Tests and Test Case/Shared Steps. These link types are used to create relationships among work items that track bugs, issues, test cases, and shared steps. For more information see Creating and Managing Tests.

Dependent links are based on a dependency topology, support one-to-many relationships, and prohibit circular definitions. You can perform any of the following tasks by using dependent links:

• Find and view top-level work items and their dependent work items in a two-tiered view. For more information, see View and Modify Work Items in a Direct Links View.

• Manage risks and dependencies and collaborate more effectively across project teams. For example, you can reach the following goals by defining dependent links between work items in your team project and those defined in another team project:

  • Create a dependent relationship to a feature or set of tasks that are under development by another team.

  • Request that another team accept a work item dependency.

  • Manage your commitments and cross-group dependencies to other teams.

When you define dependent links, note the following restrictions and recommendations:

• Use dependent links when work items share dependencies. For example, use them when a user story has many features and some of the features fulfill two or more user stories.

• Use dependent links rather than other link types to associate work items that are defined in another team project.

• You cannot view hierarchical relationships created with dependent link types using Office Excel or Office Project except for those instances noted earlier in this topic for parent-child links and predecessor-successor links. 

  Note

  You can create dependent links between work items that are defined in different projects and view the dependencies within a two-tiered or tree view in Team Web Access and Team Explorer. However, if you export a query to Office Excel or Office Project, only those work items that are defined for the team project for which the query is defined are imported into the Office client.

Use Changeset and Versioned Item Links to Associate Tasks and Features with Development Work and Versioned Items

You can create relationships between work items and version control changesets and files by using the Changeset and Versioned Item link types. These relationships are useful when you need to determine the changeset or source control file that is associated with a feature, task, bug, or other work item. To use these link relationships, your team must use Team Foundation for version control.

With Changeset and Versioned Item links you and other team members can perform the following tasks:

• Associate version control changes with a particular work item.

• Track the set of files that were involved in completing a work item.

• View changes that have been made in the source code to address a work item.

For more information, see Associate Work Items with Changesets.

See Also

Tasks

Create or Delete Relationships Between Work Items

View and Modify Work Items in a Direct Links View

View and Modify Work Items in a Tree View

Concepts

Working with Link Types

Other Resources

Quick Tips and Operational Differences when Tracking Tasks Using Microsoft Project and Team Foundation

Creating Relationships Between Work Items and Other Resources