By using the index of fields in this topic, you can look up a description of each field used to track work items. This reference includes all fields defined within the default process templates for Team Foundation Server (TFS). 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 process template for Microsoft Solutions Framework (MSF) for Agile Software Development, all fields that are defined in each Agile work item type are added to the team project collection of data fields.
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
Define and modify work item fields.
Note |
---|
You can list the attributes of fields using the witadmin listfields command. Also, you can change the field name, the index, and the report attributes for any field except system fields by using the witadmin command-line tool. For more information, see Manage work item fields [witadmin]. You can view the attribute assignments made to all fields defined in a team project collection using the Process Editor, a power tool for Visual Studio. For more information, see the following page on the Microsoft website: Team Foundation Server Power Tools. |
Alphabetical index
Values in parenthesis indicate fields that are either System fields used only by one of the default process templates: Scrum, Agile, or CMMI, or are associated with test case management (TCM). For a list of fields that are written to the relational database or data warehouse cube, see
Reportable fields reference for Visual Studio ALM.
Acceptance Criteria (Scrum) Accepted By Accepted Date Activated By Activated Date Activity Actual Attendee 1-8 (CMMI) Analysis (CMMI) Application Launch Instructions Application Start Information Application Type Area ID (System) Area Path (System) Assigned To Associated Context Associated Context Code Associated Context Owner Associated Context Type Attached File Count Authorized As (Not used) Automated Test Id (TCM) Automated Test Name (TCM) Automated Test Storage (TCM) Automated Test Type (TCM) AutomatedTestId (TCM) AutomatedTestName (TCM) Automation Status (TCM) Backlog Priority (Scrum) Blocked Business Value Called By (CMMI) Called Date (CMMI)
| Changed By (System) Changed Date (System) Closed By (System) Closed Date (System) Closed Status Closed Status Code Closing Comment Comments (CMMI) Committed (CMMI) Completed Work Contingency Plan (CMMI) Corrective Action Actual Resolution (CMMI) Corrective Action Plan (CMMI) Created By (System) Created Date (System) Discipline (CMMI) Description (System) Due Date (Agile) Effort (Scrum) Escalate (CMMI) Finish Date Found In Build (TCM) Found In Environment (CMMI) History (System) How Found (CMMI) Hyperlink Count ID (System) Impact Assessment (CMMI) Impact on Architecture (CMMI) Impact on Development (CMMI) Impact on Technical Publications (CMMI) Impact on Test (CMMI) Impact on User Experience (CMMI)
| Integrated in Build (TCM) Issue (TCM) Iteration ID (System) Iteration Path (System) Justification (CMMI) Link Comment (System) Link Description (System) Local Data Source (TCM) Meeting Type (CMMI) Minutes (CMMI) Mitigation Plan (CMMI) Mitigation Triggers (CMMI) Node Name Optional Attendee 1-8 (CMMI) Original Estimate Parameters (TCM) Priority Probability (CMMI) Proposed Fix (CMMI) Purpose (CMMI) Rating Reason (System) Related Link Count (System) Remaining Work Repro Steps Required Attendee 1-8 (CMMI) Requirement Type (CMMI) Requires Review (CMMI) Requires Test (CMMI) Resolution (Scrum) Resolved By Resolved Date Resolved Reason
| Reviewed By Reviewed Date Rev (System) Risk (Agile) Root Cause (CMMI) Severity Size (CMMI) Stack Rank Start Date State (System) State Change Date State Code Steps (TCM) Steps to Reproduce (TCM) Story Points (Agile) Subject Matter Expert 1-3 (CMMI) Symptom (CMMI) System Info (TCM) Tags Target Date Target Resolve Date (CMMI) Task Type (CMMI) Team Project (System) Test Suite Audit (TCM) Test Suite Type (TCM) Test Suite Type ID (TCM) Title (System) Triage (CMMI) User Acceptance Test (CMMI) Work Item Type (System)
|
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.
Field reference topics
The following topics describe fields that used in common by all work item types, or those that are specific to just a one or a few work item types.
Fields common to many work types: Titles, IDs, Descriptions, and History Areas and Iterations Assignments and Workflow Planning, Ranking, and Priorities Effort, Schedules, and Tracking Work Build Integration Link Controls, Restrictions, and Fields Attachment Controls and Fields
| Fields used by specific work item types: Code Review Request Code Review Response Feedback Request Feedback Response Shared Steps Test Case
| Fields used to track CMMI work items: Requirements Bugs Change Requests Issues Review Meetings Risks
|
See Also
Reference
Concepts
Work with team project artifacts, choose a process template