Categories XML element reference

You use the CATEGORIES element to define one or more categories for grouping work item types.

<CATEGORIES>
   <CATEGORY name="category display name" refname="category reference name">
      <DEFAULTWORKITEMTYPE name="work item type reference name" />
      <WORKITEMTYPE name="work item type reference name" />
   </CATEGORY>
</CATEGORIES>

Attributes and elements

Child elements and attributes

Remarks

CATEGORIES is the root element of the categories schema.

A category is defined within the CATEGORIES set of CATEGORY elements that is stored and used by a team project. Each CATEGORIES element must have at least one CATEGORY element defined.

A category cannot be empty. Each CATEGORY element must have at least one DEFAULTWORKITEMTYPE or WORKITEMTYPE element defined.

Each category has a friendly name and a reference name that must be unique within the team project. Each category friendly name must meet the following requirements:

• Names can have up to 254 Unicode characters.

• Names must not be empty.

• Names cannot have leading or trailing white spaces.

• Names cannot contain backslash (\) characters.

• Names cannot contain two consecutive white spaces.

Category friendly names are not localized and cannot be made into a token, whereas the names for work item types are localized and can be made into a token.

For reference naming conventions, see Naming conventions for work item tracking objects.

Agile tools, category requirements, and restrictions

You can specify which types of work items are considered as backlog items or as task items. For example, the Scrum process template assigns the Bug and Product Backlog Item types to the Requirements Category, whereas the Agile template assigns User Story and the CMMI template assigns Requirement. All default process templates assign the Task type of work item to the Task Category.

When assigning work item types to categories, consider the following operational notes:

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

• You cannot assign the same work item type to both the Requirements Category and to the Task Category.

• If you include more than one work item type 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 work item types 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.

Example

The following example lists the default categories XML file for the Visual Studio Scrum 2013.3 process template.

<?xml version="1.0" encoding="utf-8"?>
<cat:CATEGORIES xmlns:cat="https://schemas.microsoft.com/VisualStudio/2008/workitemtracking/categories">
  <!-- Usage: for resilience in Test system. Even if WITs have different name, they can be referred to by the category -->
  <CATEGORY name="Bug Category" refname="Microsoft.BugCategory">
    <DEFAULTWORKITEMTYPE name="Bug" />
  </CATEGORY>
  <CATEGORY name="Feature Category" refname="Microsoft.FeatureCategory">
    <DEFAULTWORKITEMTYPE name="Feature" />
  </CATEGORY>
  <CATEGORY name="Requirement Category" refname="Microsoft.RequirementCategory">
    <DEFAULTWORKITEMTYPE name="Product Backlog Item" />
    <WORKITEMTYPE name="Bug" />
  </CATEGORY>
  <CATEGORY name="Test Case Category" refname="Microsoft.TestCaseCategory">
    <DEFAULTWORKITEMTYPE name="Test Case" />
  </CATEGORY>
  <CATEGORY name="Shared Step Category" refname="Microsoft.SharedStepCategory">
    <DEFAULTWORKITEMTYPE name="Shared Steps" />
  </CATEGORY>
   <CATEGORY name="Shared Parameter Category" refname="Microsoft.SharedParameterCategory">
    <DEFAULTWORKITEMTYPE name="Shared Parameter" />
  </CATEGORY>
  <CATEGORY name="Code Review Request Category" refname="Microsoft.CodeReviewRequestCategory">
    <DEFAULTWORKITEMTYPE name="Code Review Request" />
  </CATEGORY>
  <CATEGORY name="Code Review Response Category" refname="Microsoft.CodeReviewResponseCategory">
    <DEFAULTWORKITEMTYPE name="Code Review Response" />
  </CATEGORY>
  <CATEGORY name="Feedback Request Category" refname="Microsoft.FeedbackRequestCategory">
    <DEFAULTWORKITEMTYPE name="Feedback Request" />
  </CATEGORY>
  <CATEGORY name="Feedback Response Category" refname="Microsoft.FeedbackResponseCategory">
    <DEFAULTWORKITEMTYPE name="Feedback Response" />
  </CATEGORY>
  <CATEGORY name="Test Plan Category" refname="Microsoft.TestPlanCategory">
    <DEFAULTWORKITEMTYPE name="Test Plan" />
  </CATEGORY>
  <CATEGORY name="Test Suite Category" refname="Microsoft.TestSuiteCategory">
    <DEFAULTWORKITEMTYPE name="Test Suite" />
  </CATEGORY>
  <CATEGORY name="Task Category" refname="Microsoft.TaskCategory">
    <DEFAULTWORKITEMTYPE name="Task" />
  </CATEGORY>
  <CATEGORY name="Hidden Types Category" refname="Microsoft.HiddenCategory">
    <DEFAULTWORKITEMTYPE name="Code Review Request" />
    <WORKITEMTYPE name="Code Review Response" />
    <WORKITEMTYPE name="Feedback Request" />
    <WORKITEMTYPE name="Feedback Response" />
    <WORKITEMTYPE name="Shared Steps" />
    <WORKITEMTYPE name="Shared Parameter" />
    <WORKITEMTYPE name="Test Plan" />
    <WORKITEMTYPE name="Test Suite" />
  </CATEGORY>
</cat:CATEGORIES>

Element information

See Also

Other Resources

Use categories to group work item types