Use categories to group work item types
Updated: July 15, 2016
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.
Here’s an example of the feature and bug category entries within the Categories XML definition 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 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 support portfolio backlogs. A category is defined for each WIT that supports a portfolio backlog, such as the Feature Category and Epic Category. See Add a backlog to Agile portfolio management.
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 Visual Studio Team Services (VSTS) processes and TFS default process templates:
Code Review Request Category and Code Review Response Category
Epic Category (Controls which WITs appear on the Epic portfolio backlog and Kanban board)
Feature Category (Controls which WITs appear on the Feature portfolio backlog and Kanban board)
Feedback Request Category and Feedback Response Category
Requirement Category (Controls which WITs appear on the product backlog, sprint backlogs, and Kanban board)
Shared Step Category
Shared Parameter Category
Task Category (Controls which WITs appear on the task board)
Test Case Category
Test Plan Category
Test Suite 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 Requirement Category to include two or more WITs which will then appear on the product backlog.
Process configuration defines the layout and fields used in the display of the product backlog, sprint backlogs, and portfolio backlogs. You view these pages through the web portal. Process configuration uses categories to configure and customize these functions. 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.
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: 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.
A: WITs that you add to the Requirement Category or the Task Category must belong to one or the other, but not both. To learn more, see Add bugs to the task board or backlog.
For WITs that you add to the Bug Category, you can add it to the Bug Category as well as others.
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:
Work Item Type
A: Post your questions or search for an answer in the Visual Studio TFS forum for Project Management and Work item tracking.