Using System Fields and Fields Defined by the MSF Process Templates

  • Article

You use two main types of fields to track data for a type of work item. System fields are defined for all work item types, and all other fields are created by adding FIELD element definitions for them to a work item type. When the work item type is uploaded to Team Foundation, either when a team project is created or by other means, all new fields are added to the set of fields that are defined for the team project collection. For example, when you create a team project that uses the Microsoft Solutions Framework (MSF) for Agile Software Development - v5.0 process template, all fields that are defined in each Agile work item type are added to the team project collection of data fields.

Note

This topic lists all fields that are defined in the work item type definition files of the MSF for Agile Software Development - v5.0 process template. Many of these fields are also defined in the work item type definition files of the MSF for Capability Maturity Model Integration (CMMI) Software Development - v5.0 process template. The CMMI process template is not complete in this release. Not all fields defined in the CMMI process template are described in this topic.

By using the system fields or other fields you have added to your project collection, you can enable meaningful cross-team project reports and queries. In addition, any non-system field that is referenced in the workflow or forms section of the work item type definition must have a FIELD element that defines it in the FIELDS section of the work item type definition XML file. Also, you must specify any non-system field that you might want to use to generate a query or report in the FIELDS section.

You should use as many of the system and existing project collection fields as possible to make your work item type more portable between project collections. To support additional tracking needs, you can define your own custom work item fields. For more information, see Working with Work Item Fields.

In this topic

  • Field Element Syntax

  • System Fields

  • Tracking Fields

  • Scheduling Fields

  • Build Integration Fields

  • Test Integration Fields

Fields that are used only to track types of work items for CMMI:

  • Requirements (CMMI)

  • Bugs (CMMI)

  • Change Requests (CMMI)

  • Issues(CMMI)

  • Review Meetings(CMMI)

  • Risks(CMMI)

  • Tasks (CMMI)

FIELD Element Syntax

The following syntax structure and attributes define fields:

<FIELD name="field display name" refname="field reference name" type="String | Integer | 
Double | DateTime | PlainText | HTML | History | TreePath | GUID " 
syncnamechanges="true | false" reportable="Dimension | Detail | Measure" formula="sum" 
indexable="true | false" >
</FIELD>

Later in this topic, you will find brief descriptions and the default attribute assignments for each system and MSF Agile defined field. Note the following information about the specification of attributes:

  • You can specify a field name that you want and have it be different in different work item definitions. All field data is tracked based on the reference name.

  • The type attribute specifies the data type for the field. For a description of each data type, see Working with Work Item Fields. For information about the controls that display specific field types, see Specifying Work Item Form Controls.

  • String fields that are used to store person names should have the syncnamechanges attribute set to true. This setting indicates that the contents of the field should be updated as changes are made to person names in Active Directory or a workgroup.

  • Fields that have their Reportable attribute assigned a value of Detail, Dimension, or Measure are tracked in the data warehouse. For more information, see Working with Work Item Fields.

  • The Indexable attribute is set to True to increase the performance of running queries that specify that field in the filter criteria. If you add a custom field that you use in many of your work item queries, you may want to enable indexing for that field.

You can change the field name and the Reportable and Indexable attribute assignments for any field, except system fields, by using the witadmin command-line tool. For more information, see Managing Work Item Fields [witadmin].

Back to top

System Fields

You can use two types of system fields as described in the following sections:

  • Fields Used for Tracking Work Items

  • Fields Used for Tracking Link Relationships

System Fields Used for Tracking Work Items

The following table lists the supported system fields that track your work items and their assigned default values.

Field Name

Reference Name

Type

Description

Default Reportable Field Value

Default Indexed Field Value

Area

System.AreaPath

TreePath

Used to group the task into an appropriate feature or team area. The area must be a valid node in the project hierarchy. For more information, see Create and Modify Areas and Iterations.

Dimension

True

Area ID

System.AreaId

Integer

The unique ID of the area to which this work item belongs.

None

True

Assigned To

System.AssignedTo

String

The name of the team member that is the current owner of the work item.

Dimension

True

Attached File Count

System.AttachedFileCount

Integer

The number of file attachments.

None

False

Authorized As

System.AuthorizedAs

String

The name of the authenticated user who made the last change.

None

False

Changed By

System.ChangedBy

String

The name of the team member who last modified the work item.

Dimension

True

Changed Date

System.ChangedDate

DateTime

Date and time when the current revision was overwritten by a new revision.

Dimension

False

Created By

System.CreatedBy

String

The name of the team member who created the work item.

Dimension

True

Created Date

System.CreatedDate

DateTime

Date and time the work item was created.

Dimension

True

Description

System.Description

PlainText

The long description of a work item. A text field that provides a more detailed description of the work item than the title provides.

None

False

External Link Count

System.ExternalLinkCount

Integer

The number of links from this work item to non-work item artifacts registered by using the Team Foundation Linking Service. For more information, see this topic on the Microsoft Web site: Linking Service.

None

False

History

System.History

History

The record of changes that were made to the work item after it was created. Every time that the work item is updated, information is appended to the history, which specifies the date, who made the change, and the fields that were changed. You can also add text to the history field.

None

False

Hyper Link Count

System.HyperLinkCount

Integer

The number of hyperlinks that are defined for the work item.

None

False

ID

System.Id

Integer

The unique ID of the work item. Work item IDs are unique across all team projects in a team project collection..

Dimension

True

Iteration

System.IterationPath

TreePath

Groups work items by named sprints or time periods. The iteration must be a valid node in the project hierarchy.

For more information, see Create and Modify Areas and Iterations.

Note that the TreePath field type cannot be used for any other fields or user-defined fields.

Dimension

True

Iteration ID

System.IterationId

Integer

The unique ID of the iteration to which this work item belongs.

None

True

Node Name

System.NodeName

String

The name of the parent node to which this work item belongs. The value for this field is the same as the team project.

None

False

Reason

System.Reason

String

The reason the work item is in the current state. Values are specific to the state. The Reason field supports only the HELPTEXT and READONLY rule types.

This field is not tracked for test cases or shared steps.

Dimension

True

RelatedLinkCount

System.RelatedLinkCount

Integer

The number of links from this work item to other work items.

None

False

Rev

System.Rev

Integer

A number that is assigned to the historical revision of a work item.

Dimension

False

State

System.State

String

The current state of the work item. The valid values for state are specific for each work item type. The State field supports only the HELPTEXT and READONLY rule types.

For more information about workflow transitions for each type of work item, see Work Items and Workflow (Agile).

Dimension

True

Team Project

System.TeamProject

String

The team project to which this work item belongs.

Dimension

False

Title

System.Title

String

A one-line summary of the work item that helps users distinguish it from other work items in a list.

Dimension

True

Work Item Type

System.WorkItemType

String

The name of the work item type of this work item.

Dimension

True

Back to top

The following table lists the system fields used to track link relationships. These are link attributes.

Field Name

Reference Name

Type

Description

Default Reportable Field Value

Default Indexed Field Value

Link Description

System.Links.Description

PlainText

Contains the work item type, ID, and title of the work item that is the target of the link. This field can be selected to appear as a column in a link list on a work item form.

None

False

Link Comment

System.Links.Comment

PlainText

Contains the comments entered by a team member when a link relationship is created between two work items. This field can be selected to appear as a column in a link list on a work item form.

None

False

Back to top

Tracking Fields

The following table lists the fields that are used to track the progress, state, and priority of work item types. These fields are defined in the work item type definitions for MSF for Agile Software Development - v5.0 and MSF for CMMI Process Improvement - v5.0.

Field Name

Reference Name

Type

Description

Default Reportable Field Value

Default Indexed Field Value

Activated By

Microsoft.VSTS.Common.ActivatedBy

String

Name of the team member who activated or reactivated the work item.

Dimension

False

Activated Date

Microsoft.VSTS.Common.ActivatedDate

DateTime

Date and time when the work item was activated or reactivated.

Dimension

False

Activity

Microsoft.VSTS.Common.Activity

String

Type of activity required to perform a work item task.

Dimension

False

Closed By

Microsoft.VSTS.Common.ClosedBy

String

Name of the team member who closed the work item.

Dimension

False

Closed Date

Microsoft.VSTS.Common.ClosedDate

DateTime

Date and time when a work item was closed.

Dimension

False

Priority

Microsoft.VSTS.Common.Priority

Integer

A subjective rating of the bug, issue, task, or test case as it relates to the business. You can specify the following values:

  • 1:  Product cannot ship without the successful resolution of the work item, and it should be addressed as soon as possible.

  • 2:  Product cannot ship without the successful resolution of the work item, but it does not need to be addressed immediately.

  • 3:  Resolution of the work item is optional based on resources, time, and risk.

Dimension

False

Rank

Microsoft.VSTS.Common.Rank

Double

A subjective rating of the user story, task, issue, or bug compared to other work items of the same type. An item that is assigned a lower number should be fixed before an item that is assigned a higher number.

Dimension

False

Resolved By

Microsoft.VSTS.Common.ResolvedBy

String

Name of the team member who resolved the bug.

Dimension

False

Resolved Date

Microsoft.VSTS.Common.ResolvedDate

DateTime

Date and time when the bug was resolved

Dimension

False

Resolved Reason

Microsoft.VSTS.Common.ResolvedReason

String

Records why the bug, change request, issue, requirement, review, risk, or task was resolved. For example, the requirement is code complete or the bug is fixed.

This field is read-only.

Dimension

False

Risk

Microsoft.VSTS.Common.Risk

String

A subjective rating of the relative uncertainty around the successful completion of the user story. You can specify the following values:

  • 1 - High

  • 2 - Medium

  • 3 - Low

Dimension

False

Severity

Microsoft.VSTS.Common.Severity

String

A subjective rating of the impact of a bug on the project. You can specify the following values:

  • 1 - Critical

  • 2 - High

  • 3 - Medium

  • 4 - Low

Dimension

False

Stack Rank

Microsoft.VSTS.Common.StackRank

Double

Work first on items with lower-valued stack rank. Set in triage.

Dimension

False

State Change Date

Microsoft.VSTS.Common.StateChangeDate

DateTime

Date and time that the value of the State field changed.

None

False

Task Type

Microsoft.VSTS.Common.TaskType

String

Type of requirement most affected by a bug. Suggested values are Functional, Performance, Security, Usability, and Guidance.

Dimension

False

The following table describes the fields that track assignments and workflow progress for work items that are defined in the CMMI process template.

Field name

Reference name

Data type

Description

Default value of the reportable type attribute

Default value of the index attribute

Blocked

Microsoft.VSTS.CMMI.Blocked

String

Indicates whether a team member is prevented from making progress toward implementing a requirement or a task or resolving a bug, an issue, a task, or a change request. If an issue has been opened to track a blocking problem, a link should be made to the issue.

You can specify Yes or No.

Dimension

False

Committed

Microsoft.VSTS.CMMI.Committed

String

Indicates whether the requirement is committed in the project or not. You can specify Yes or No.

NoteNote
You can specify this field only for requirements.

None

False

Escalate

Microsoft.VSTS.CMMI.Escalate

String

Indicates whether the issue affects the critical path of the project plan. You can specify Yes or No.

NoteNote
You can specify this field only for issues.

None

False

Probability

Microsoft.VSTS.CMMI.Probability

Integer

Specifies the probability that the risk will occur, as a number between 1 and 99. A higher number indicates that the risk is more likely to occur.

NoteNote
You can specify this field only for risks.

None

False

Triage

Microsoft.VSTS.Common.Triage

String

Indicates the type of triage decision that is pending for the work item. You use this field when the work item is in the Proposed state.

You can specify one of the following values:

  • Pending (default)

  • More Info

  • Info Received

  • Triaged

NoteNote
You can specify this field only for requirements, tasks, change requests, bugs, and issues.

Dimension

False

Requires Review

Microsoft.VSTS.CMMI.RequiresReview

String

Indicates whether the work that the task implements requires a formal review. You can specify Yes or No.

If you specify Yes, you should also create a review work item and link to it from the task.

None

False

Requires Test

Microsoft.VSTS.CMMI.RequiresTest

String

Indicates whether the work that a task implements requires testing. You can specify Yes or No.

If you specify Yes, you should create a test case and link to it from the task.

None

False

Target Resolve Date

Microsoft.VSTS.CMMI.TargetResolveDate

DateTime

The forecasted date by which an issue will be resolved. This field applies only to issues.

Dimension

False

Back to top

Scheduling Fields

The following table describes the fields that are available for scheduling and work item tracking. These fields are defined in the work item type definitions for MSF for Agile Software Development - v5.0 and MSF for CMMI Process Improvement - v5.0. These fields are synchronized with Office Project and can be used when the Office Project version of the iteration plan is chosen. For more information, see Scheduling Tasks and Assigning Resources Using Microsoft Project and Customizing Microsoft Project Field Mappings.

Field Name

Reference Name

Type

Description

Default Reportable Field Value

Default Indexed Field Value

Completed Work

Microsoft.VSTS.Scheduling.CompletedWork

Double

The number of hours that were spent working on a task.

Measure, Sum

False

Due Date

Microsoft.VSTS.Scheduling.DueDate

DateTime

The forecasted date for an issue to be completed. This field applies only to issue work items for the agile process template.

Dimension

False

Finish Date

Microsoft.VSTS.Scheduling.FinishDate

DateTime

The date and time that the schedule indicates that the work item will be completed.

Dimension

False

Original Estimate

Microsoft.VSTS.Scheduling.OriginalEstimate

Double

The number of hours that was determined was required to complete a task.

Measure, Sum

False

Remaining Work

Microsoft.VSTS.Scheduling.RemainingWork

Double

The number of hours that remain to finish the task.

Measure, Sum

False

Start Date

Microsoft.VSTS.Scheduling.StartDate

DateTime

The date and time that the schedule indicates that the work item will start.

Dimension

False

Story Points

Microsoft.VSTS.Scheduling.StoryPoints

Double

A subjective unit of measure that captures the size of a user story. If you assign more points to a user story, you indicate that more work is required to implement it.

This field is defined only in the MSF process template for agile software development.

Measure

Sum

Build Integration Fields

The following table describes the fields that are available for you to integrate build information into work item tracking. These fields are defined in the work item type definitions for MSF for Agile Software Development - v5.0 and MSF for CMMI Process Improvement - v5.0.

Field Name

Reference Name

Type

Description

Default Reportable Field Value

Indexed

Found In

Microsoft.VSTS.Build.FoundIn

String

Product build number, also known as a revision, in which a bug was found.

Dimension

False

Integration Build

Microsoft.VSTS.Build.IntegrationBuild

String

Product build number that incorporates the code or fixes a bug.

Dimension

False

Back to top

Test Integration Fields

The following table describes the fields that are used by Microsoft Test Manager and the test case and shared steps types of work items. These fields are defined in the work item type definitions for MSF for Agile Software Development - v5.0 and MSF for CMMI Process Improvement - v5.0. For more information about the use of these fields, see Creating and Managing Tests.

Field Name

Reference Name

Type

Description

Default value of the reportable type attribute

Default value of the index attribute

Automated Test Id

Microsoft.VSTS.TCM.AutomatedTestId

String

The ID of the test that automates the test case.

None

False

Automated Test Name

Microsoft.VSTS.TCM.AutomatedTestName

String

The name of the test that is used to automate the test case.

None

False

Automated Test Storage

Microsoft.VSTS.TCM.AutomatedTestStorage

String

The assembly that contains the test that automates the test case.

None

False

Automated Test Type

Microsoft.VSTS.TCM.AutomatedTestType

String

The type of test that automates the test case.

None

False

Automation Status

Microsoft.VSTS.TCM.AutomationStatus

String

The status of a test case. You can specify the following values:

  • Not Automated

  • Planned

Detail

False

Local Data Source

Microsoft.VSTS.TCM.LocalDataSource

HTML

The local data source that supports the test.

None

False

Parameters

Microsoft.VSTS.TCM.Parameters

HTML

The parameters to be tested.

None

False

Repro Steps

Microsoft.VSTS.TCM.ReproSteps

HTML

The steps required to reproduce unexpected behavior.

None

False

Steps

Microsoft.VSTS.TCM.Steps

HTML

The steps required to perform the test.

None

False

System Info

Microsoft.VSTS.TCM.SystemInfo

HTML

Information about the software and system configuration that is relevant to the test.

None

False

Back to top

Fields that Are Tracked Only for Requirements (CMMI)

The following table describes fields that you can use to track the type of Requirement to be developed and its importance to the overall product.

Field name

Reference name

Data type

Description

Default value of the reportable type attribute

Default value of the index attribute

Requirement Type

Microsoft.VSTS.CMMI.RequirementType

String

Specifies the kind of requirement to implement. You can specify one of the following values:

  • Business Objective

  • Feature (default)

  • Functional

  • Interface

  • Operational

  • Quality of Service

  • Safety

  • Scenario

  • Security

Dimension

False

Impact Assessment

Microsoft.VSTS.CMMI.ImpactAssessmentHtml

HTML

Describes the customer impact of not implementing this requirement. You might include details from the Kano model about whether this requirement is in the surprise, required, or obvious categories.

None

False

User Acceptance Test

Microsoft.VSTS.CMMI.UserAcceptanceTest

String

Specifies the status of the user acceptance test for a requirement. You can specify one of the following values:

  • Pass (default)

  • Fail

  • Not Ready

  • Ready

  • Skipped

  • Info Received

You specify Not Ready when the requirement is in the Active state, and you specify Ready when the requirement is in the Resolved state.

None

False

Subject matter experts

Microsoft.VSTS.CMMI.SubjectMatterExpert1

…

Microsoft.VSTS.CMMI.SubjectMatterExpert3

String

Specifies up to three team members who are familiar with the customer area that this requirement represents.

You can specify the names of valid team members only.

None

False

Back to top

Fields that are Used Only to Track Bugs (CMMI)

The fields that the following table describes are neither reported nor indexed.

Field name

Reference name

Data type

Description

Symptom

Microsoft.VSTS.CMMI.Symptom

HTML

Describes the unexpected behavior.

Proposed Fix

Microsoft.VSTS.CMMI.ProposedFix

HTML

Describes the proposed change to fix the reported problem.

Found in Environment

Microsoft.VSTS.CMMI.FoundInEnvironment

String

Describes the software setup and configuration where the bug was found.

Root Cause

Microsoft.VSTS.CMMI.RootCause

String

Describes the cause of the error. You can specify one of the following values:

  • Coding Error

  • Design Error

  • Specification Error

  • Communication Error

  • Unknown

How Found

Microsoft.VSTS.CMMI.HowFound

String

Describes how the bug was found. For example, a bug might have been found during a customer review or through ad-hoc testing.

Back to top

Fields that are Used Only to Track Change Requests (CMMI)

The following table describes the fields that are used only to track change requests. The process template for MSF CMMI Process Improvement v5.0 provides the change request type of work item. For more information, see Change Request (CMMI).

These fields are not reportable or indexed.

Field name

Reference name

Data type

Description

Justification

Microsoft.VSTS.CMMI.Justification

HTML

Describes why the change has been proposed and what value it would bring to the product and the customer.

Impact on Architecture

Microsoft.VSTS.CMMI.ImpactOnArchitecture

HTML

Describes the impact that the change would have on architecture. You can use this field to describe in detail which sections of the architecture would be affected and how much the change would cost to implement.

Impact on User Experience

Microsoft.VSTS.CMMI.ImpactOnUserExperience

HTML

Describes the impact that the change would have on the user experience. You can use this field to describe in detail which sections of the user interface would be affected and how much the change would cost to implement.

Impact on Test

Microsoft.VSTS.CMMI.ImpactOnTest

HTML

Describes the impact that the change would have on testing. You can use this field to describe in detail which tests would be affected and how much the change would cost to implement.

Impact on Development

Microsoft.VSTS.CMMI.ImpactOnDevelopment

HTML

Describes the impact that the change would have on development and product designs. You can use this field to describe in detail which development areas and designs would be affected and how much the change would cost to implement.

Impact on Technical Publications

Microsoft.VSTS.CMMI.ImpactOnTechnicalPublications

HTML

Describes the impact that the change would have on product documentation. You can use this field to describe in detail which sections of documentation would be affected and how much the change would cost to implement.

Back to top

Fields that Are Used Only to Track Issues (CMMI)

The fields that the following table describes are not indexed.

Field name

Reference name

Data type

Description

Default value of the reportable type attribute

Analysis

Microsoft.VSTS.CMMI.Analysis

HTML

Describes the root cause of the issue and one or more solutions that might resolve it.

None

Corrective Action Actual Resolution

Microsoft.VSTS.CMMI.CorrectiveActionActualResolution

HTML

Describes what the team actually did to correct the issue.

None

Corrective Action Plan

Microsoft.VSTS.CMMI.CorrectiveActionPlan

HTML

Describes the proposed corrective action on which the team has agreed.

None

Impact on project promise

Microsoft.VSTS.Common.Severity

String

Specifies a subjective rating of the impact of a bug on the project. You can specify the following values:

  • 1 - Critical

  • 2 - High

  • 3 - Medium

  • 4 - Low

NoteNote
The name of the field that appears in the query editor is Severity. You also use this field to track the severity for bugs and risks.

Dimension

Target Resolve Date

Microsoft.VSTS.CMMI.TargetResolveDate

DateTime

Specifies a date for when the issue becomes critical and starts to affect the critical path of the project plan.

None

Fields that Are Used Only to Track Risks (CMMI)

The fields that the following table describes are neither reported nor indexed.

Field name

Reference name

Data type

Description

Contingency Plan

Microsoft.VSTS.CMMI.ContingencyPlan

HTML

Describes the actions to take if the risk occurs.

You can create and link tasks to the risk work item to track the work that the team must complete to implement the contingency plan. Also, you can create an issue work item to track one or more issues on which the risk has an impact.

Mitigation Plan

Microsoft.VSTS.CMMI.MitigationPlan

HTML

Describes the actions to take to reduce the probability or impact of the risk.

You can create and link tasks to the risk work item to track the work that the team must complete to implement the mitigation plan.

Mitigation Triggers

Microsoft.VSTS.CMMI.MitigationTriggers

HTML

Describes the conditions or events that determine how the team might mitigate a risk. For example, the triage team might authorize and obtain a reserve generator if the weather forecast is predicting an ice storm or hurricane to hit within 50 miles of the office within the next four days.

Probability

Microsoft.VSTS.CMMI.Probability

Integer

Indicates the chance that the risk will occur. A valid probability number is between 1 and 99, where 99 indicates that the risk is almost certain to occur.

Back to top

Fields That Are Used Only to Track Review Meetings (CMMI)

The following table describes fields that your team can use to track information and changes for review meetings. Your team can specify this kind of information by using the review type of work item that is provided with the process template for Microsoft Solutions Framework (MSF) CMMI Process Improvement v5.0.

These fields are not reportable or indexed.

Field name

Reference name

Data type

Description

Purpose

Microsoft.VSTS.CMMI.Purpose

HTML

Describes the purpose and focus of the meeting.

Comments

Microsoft.VSTS.CMMI.Comments

HTML

Describes additional information that you want to record.

Minutes

Microsoft.VSTS.CMMI.Minutes

HTML

Describes the details of what the team discussed and agreed upon during the meeting. You can use this field to record what the team reviewed, what criteria the team applied, and what problems the team identified.

Meeting Type

Microsoft.VSTS.CMMI.MeetingType

String

Specifies the meeting venue. You can specify one of the following values:

  • Meeting

  • Offline

Called Date

Microsoft.VSTS.CMMI.CalledDate

DateTime

Specifies the date and time when the meeting is scheduled.

Called By

Microsoft.VSTS.CMMI.CalledBy

String

Specifies the name of the team member who scheduled the meeting.

Required Attendee 1

…

Required Attendee 8

Microsoft.VSTS.CMMI.RequiredAttendee1

…

Microsoft.VSTS.CMMI.RequiredAttendee8

String

Specifies the name of one or more team members who are required to attend the meeting.

Optional Attendee 1

…

Optional Attendee 8

Microsoft.VSTS.CMMI.OptionalAttendee1

…

Microsoft.VSTS.CMMI.OptionalAttendee8

String

Specifies the name of one or more team members who are invited but not required to attend the meeting.

Actual Attendee 1

…

Actual Attendee 8

Microsoft.VSTS.CMMI.ActualAttendee1

…

Microsoft.VSTS.CMMI.ActuallAttendee8

String

Specifies the name of one or more team members who attended the meeting.

Back to top

Fields That Are Used Only to Track Tasks (CMMI)

The following table describes fields that you can use to track the type of task on which the team is working.

Field name

Reference name

Data type

Description

Default value of the reportable type attribute

Default value of the index attribute

Discipline

Microsoft.VSTS.Common.Discipline

String

Specifies the discipline of the team member who will complete the task. You can specify one of the following values:

  • Analysis

  • User Experience

  • User Education

  • Development

  • Test

Dimension

None

Task Type

Microsoft.VSTS.CMMI.TaskType

String

Specifies the kind of task to implement. You can specify one of the following values:

  • Corrective Action

  • Mitigation Action

  • Planned

Dimension

None

Back to top

See Also

Reference

Managing Work Item Fields [witadmin]

Concepts

Naming Conventions for Work Item Tracking Objects

Working with Work Item Fields

Other Resources

Work Item Fields (Agile)

Work Item Fields (CMMI)

Defining Work Item Fields