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.
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:
Code Review Request Category and Code Review Response Category
Feedback Request Category and Feedback Response Category
Shared Step Category
Test Case Category
Hidden Types Category
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:
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 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 includes Code Review Request and Code Review Response, Feedback Request and Feedback Response, and Shared Steps. These WITs support the feedback and code review experiences, as well as the definition of test cases.
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: 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.
A: Post your questions or search for an answer in the Visual Studio TFS forum for Project Management and Work item tracking.