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 Requirement Category. To add WITs to appear on the task board page, add them to the Task Category. See Add bugs or other work item types to backlogs or boards.

• 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.

Default categories and process configuration

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. Included when you upgrade to TFS 2013.2.

3. Controls which WITs appear on the task board.

4. Included when you 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 Requirement Category to include two or three WITs that you can add through the product backlog.

Process configuration

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 Requirement Category and one WIT to the Task Category.

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

• If you include more than one WIT in the Requirement 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.

Hidden Types category

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

• Code Review Request and Code Review Response

• Feedback Request and Feedback Response

• Shared Steps and Shared Parameter

• Test Plan and Test Suite

Q & A

Q: How do I add a category?

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].

Q: Can I add a WIT to more than one category?

A: WITs that you add to the Requirement 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. To learn more, see Add bugs or other work item types to backlogs or boards.

Q: How are categories named?

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.

Q: Can I filter a query based on a category?

A: Yes. Use the In Group operator along with the Work Item Type field. For example, the following filter criteria will return all work items that are in the current team project, assigned to the team member, and defined as belonging to the Bug Category:

Q: What if I have more questions?

A: Post your questions or search for an answer in the Visual Studio TFS forum for Project Management and Work item tracking.