All WITD XML Elements Reference
You can customize an existing work item type or create a work item type to meet your project tracking requirements. A work item type defines the rules, fields, states, and transitions for an item of work that will be tracked for a team project, such as a bug, requirement, or risk.
A work item type cannot be empty. The root element in each definition of a work item type is the WITD element, which must have only one WORKITEMTYPE element defined. The name of each work item type must be unique in a team project, and each type name must be no more than 254 Unicode characters long. For more information, see Naming Conventions for Work Item Tracking Objects.
To customize or create a work item type definition, you modify the type definition XML file associated with the work item type. You maintain and manage definitions of types of work items for each team project.
In this topic
WITD Syntax Structure
WITD Child Elements
Process Template Work Item Types
WITD Syntax Structure
The following example shows the high-level structure of a work item type.
<WITD application="work item type editor" version="1.0">
<WORKITEMTYPE name="bug">
<DESCRIPTION>Bug work item types are used to track defects in the code.</DESCRIPTION>
<GLOBALLISTS> . . . </GLOBALLISTS>
<FIELDS> . . . </FIELDS>
<WORKFLOW> . . . </WORKFLOW>
<FORM> . . . </FORM>
</WORKITEMTYPE>
</WITD>
A small number of XML elements appear between WORKITEMTYPE tags at the highest levels of the work item type definition. You start defining a work item type by providing a name and a description. You also use certain standard XML tags to wrap the work item type definition.
WITD Child Elements
The structural elements used in the previous example are described in the following table:
Element |
Description |
|---|---|
WITD |
The complete work item type definition is wrapped by the tag WITD. You can use any name for the application name. The version identifies the schema of the work item type that changes from one release to the next. Use "1.0". |
WORKITEMTYPE |
Names of work item types must be unique in a specific team project. At run time, you use the name specified by this element. For example, the name can appear as a menu option. In this case, a user could click Bug on the New Work Item menu. |
DESCRIPTION |
Specifies a string that describes the type of work item that you are defining. The description should help any user who is customizing the type of work item. Note You can view the description only in the XML definition. You cannot view the description anywhere in the user interface, and it has no relationship to the field System.Definition. You specify a string of text that describes the type of work item that you are defining. |
GLOBALLISTS |
Contains the global list definitions that are used by the work item type. You use global lists to share list items among multiple work item types for a team project collection. Using global lists provides support for ease of maintenance and cross-group collaboration. For more information, see Define Global Lists. |
FIELDS |
Contains the set of field definitions that are used by the work item type. Within the FIELDS element, you define all the fields that you want to use to track data for the type of work item. This includes fields that you will use to run queries and generate reports. For more information, see Working with Work Item Fields. |
WORKFLOW |
Contains the set of STATE and TRANSITION elements that define the workflow of the work item type. The workflow is a set of valid transitions from one state to another and the specific conditions associated with each transition. For more information, see Define and Customize Work Item Workflow. |
FORM |
Contains LAYOUT, CONTROL, GROUP, TAB, TABGROUP, SPLITTER, and other elements that define which fields and controls appear on the form and the display of these elements on the form for the work item type. For more information, see Design and Customize a Work Item Form. |
Process Template Work Item Types
Two sets of process template work item type definitions are available for you to use which correspond to those defined for the Microsoft Solutions Framework (MSF) for Agile Software Development v5.0 and MSF for Capability Maturity Model Integration (CMMI) Software Development v5.0. These files are located in the installation directory in the following locations, respectively:
Drive:\Program Files\Microsoft Visual Studio v10.0 Team Foundation Server\Application Tier\Web Services\Deploy\ProcessTemplateManagerFiles\MsfAgile\Template.zip
Drive:\Program Files\Microsoft Visual Studio v10.0 Team Foundation Server\Application Tier\Web Services\Deploy\ProcessTemplateManagerFiles\MsfFormal\Template.zip
You can find the work item type definitions in the WorkItem Tracking\TypeDefinitions folder of the Template.zip file. For example, MSF for Agile Software Development v5.0 defines an XML file for each of the following work item types: Bug, Issue, SharedStep, Task, TestCase, and User Story. For more information about each of these work item types, see MSF for Agile Software Development 6.0.
You can customize or create type definition files in the TypeDefinitions folder. Then you can import your new work item type to a single project, or you can add it to your process template and upload the modified template to your Team Foundation Server. For more information, see Add Type Definitions for Work Items to a Process Template.
See Also
Concepts
Design and Customize a Work Item Form
Customize Project Tracking Data, Forms, Workflow, and Other Objects