Export (0) Print
Expand All

Use categories to group work item types

By using categories, you can generate flexible reports and support increased integration across team projects. You can more easily manage multiple work item types (WITs) as a group as well as WITs that are named differently. Also, you can use the In Group query operator to filter a list of work items based on the category to which they belong.

Categories associate one or more WITs as belonging to the same category. The Agile planning tools rely on the default category definitions, many of which specify a single WIT per category.

Categories are defined through an XML definition file. Here’s an example of the feature and bug category entries within this file:

<CATEGORY name="Bug Category" refname="Microsoft.BugCategory">
    <DEFAULTWORKITEMTYPE name="Bug" />
  </CATEGORY>
  <CATEGORY name="Feature Category" refname="Microsoft.FeatureCategory">
    <DEFAULTWORKITEMTYPE name="Feature" />
  </CATEGORY>

You use categories to accomplish the following operations:

  • To add WITs to appear on the backlog page, you add them to the Requirements Category. To add WITs to appear on the task board page, add them to the Task Category. See Add bugs to the task board or backlog.

  • To add WITs that you use in similar ways that the Bug type is used, add them to the Bug Category. See Support bug update status using My Work.

  • To prevent users from creating WITs that should be created through a form or a tool, and not manually, add them to the Hidden Types Category.

  • To query for different WITs that have different names based on locale, assign them to the same category and use the In Group operator.

Process configuration references the default categories defined for a team project. Here are the default categories that are defined in each of the TFS process templates:

  • Bug Category

  • Code Review Request Category and Code Review Response Category

  • Feature Category

  • Feedback Request Category and Feedback Response Category

  • Requirement Category (See Note 1)

  • Shared Step Category

  • Shared Parameter Category (See Note 2)

  • Task Category (See Note 3)

  • Test Case Category

  • Test Plan Category (See Note 4)

  • Test Suite Category (See Note 4)

  • Hidden Types Category

Notes:

  1. Controls which WITs appear on the backlog and sprint backlog pages.

  2. Requires upgrade to TFS 2013.2.

  3. Controls which WITs appear on the task board.

  4. Requires upgrade to TFS 2013.3.

Most of these categories are self-explanatory, and most only contain one WIT within the category. The exception to this rule is the Hidden Types Category.

If you have created WITs that act in similar ways and you want to treat them in similar ways as those defined by the above categories, then you will want to add them to the category. For example, if you have defined one or more types of bugs, then you might want to add those types to the Bug Category. In this way, the process configuration will automatically treat these bug types as they do the standard bug WIT. Or, you can customize the Requirements Category to include two or three WITs that you can then add to the product backlog or set to appear on the task board.

Process configuration defines the layout and fields used in the display of the product backlog, task board, and portfolio backlog pages. You view these pages through Team Web Access (TWA). Process configuration uses categories to configure these functions. To customize these functions, first review Process configuration XML element reference. Also, note the following restrictions:

  • To use the backlog and task boards, you must assign at least one WIT to the Requirements Category and one WIT to the Task Category.

  • You cannot assign the same WIT to both the Requirements Category and to the Task Category.

  • If you include more than one WIT in the Requirements Category or the Task Category, the type assigned to the DEFAULTWORKITEMTYPE element appears as the default type on the Agile backlog and board pages.

  • For all WITs that you assign to a category that is referenced in the ProcessConfiguration file, you must assign the workflow states to a valid metastate as described in Process Configuration XML element reference. Several Team Foundation clients reference the category and metastate assignments defined in the ProcessConfiguration file.

The Hidden Types Category specifies the set of WITs that you do not want users to create manually. By default this set includes:

  1. Code Review Request and Code Review Response

  2. Feedback Request and Feedback Response

  3. Shared Steps and Shared Parameter

  4. Test Plan and Test Suite

A: To modify the categories defined for a team project, you export the XML definition file, make changes, and then import it using the witadmin command line tool. See Import and export categories [witadmin].

A: WITs that you add to the Requirements Category or the Task Category must belong to one or the other, but not both. For the Bug Category, you can add it to the Bug Category as well as others.

A: Each category has a friendly name and a reference name that must be unique within the team project. For more information, see Categories XML element reference.

Show:
© 2014 Microsoft