Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020
Use work items to track features, requirements, code defects, bugs, and project issues or risks. Each work item uses a work item type that determines which fields are available for tracking information. The work item types available depend on the process used when your project was created: Agile, Basic, Scrum, or CMMI.
Each work item is an object stored in the work item data store and receives a unique identifier within an organization or project collection.
If you're getting started, read this article. To start tracking work on a board, see Plan and track work. For a quick reference to common work item tasks and concepts, see Work item quick reference.
Track work with different work item types
Choose a specific work item type to track different kinds of work. The following images show the default work item types for the four default processes. Your backlog items might appear as User Stories (Agile), Issues (Basic), Product Backlog Items (Scrum), or Requirements (CMMI). All these work item types describe customer value and expose fields for tracking related information.
The following image shows the hierarchy for the Agile process backlog work item:
- User Stories and tasks are used to track work.
- Bugs track code defects.
- Epics and features are used to group work under larger scenarios.
Each team can configure how they manage Bug work items at the same level as User Story or Task work items. Use the Working with bugs setting. For more information about using these work item types, see Agile process.
Each work item type belongs to a category. Categories group work item types and determine which types appear on backlogs and boards.
| Category | Work item type | Controls backlogs/boards |
|---|---|---|
| Epic | Epic | Epic portfolio backlogs and boards |
| Feature | Feature | Feature portfolio backlogs and boards |
| Requirement | User Story (Agile) Issue (Basic) Product Backlog Item (Scrum) Requirement (CMMI) |
Product backlogs and boards and Sprints backlog |
| Task | Task | Sprint backlogs and Taskboards |
| Bug | Bug | Dependent on team configuration for tracking bugs |
The Issue (Agile and CMMI) and Impediment (Scrum) work item types track nonwork project elements that can affect work delivery. By default, they don't appear on any backlog or board.
For other work item types, see Work item types to track testing, reviews, and feedback later in this article.
Track bugs as requirements or tasks
Teams choose how to track bugs. You can show bugs on the product backlog and board (track as requirements), track them like tasks (link to a user story or product backlog item), or not track them on backlogs. To configure this option, see Show bugs on backlogs and boards. For an overview of team settings, see Manage teams and configure team tools.
Customize a work item type
Add or revise fields in a work item type, create a custom work item type, or adjust which types appear on backlogs and boards. Which customization options you can use depends on your project's process model. See:
Work item form and Details tab
The work item form displays the fields you use to track information for each work item. Update a work item from its form or by using bulk import, export, or programmatic methods.
The Details tab contains common fields, other fields defined for the work item type, and the Discussion control. Common fields appear at the top of the form and include Title, Assigned To, State, Reason, Area, and **Iteration—you can update these fields at any time.
Work item form controls
| Control | Function |
|---|---|
 |
Copy the work item URL to the clipboard (appears when you hover over the work item title) |
 |
Open the Discussions section |
|
Open the Actions menu for more work item tasks |
 |
Refresh the work item with the latest changes |
 |
Revert changes to the work item |
 |
Open the History tab |
 |
Open the Links tab |
 |
Open the Attachments tab |
 /  |
Enter or exit full display mode for a section within the form |
 / |
Collapse or expand a section within the form |
 |
Add a new work item and link it to an existing work item (might appear under the Actions menu) |
 |
Change work item type (Appears under the Actions menu) |
 |
Move work item to a different project (Appears under the Actions menu) |
 |
Copy work item and optionally change work item type (Appears under the Actions menu) |
 |
Send email with a work item (Appears under the Actions menu) |
 |
Recycle work item (Appears under the Actions menu) |
 |
Storyboard with PowerPoint (Appears under the Actions menu) |
Copy the URL
From the web portal, copy the URL from the browser address bar or hover over the title and select the 
copy icon. For other options, see Copy or clone work items.
Common work tracking fields
The following common fields appear in the header area of most work item forms. The only required field for all work item types is Title. When you save the work item, the system assigns a unique ID. The form highlights required fields in yellow. For descriptions of other fields, see Work item field index.
Note
Other fields might be required depending on customizations made to your process and project.
| Field | Usage |
|---|---|
| Title | Enter a description of 255 characters or less. You can modify the title later. |
| Assigned To | Assign the work item to the team member responsible for the work. The drop-down lists team members or contributors depending on context. |
| State | When you create the work item, the State defaults to the first workflow state. Update it to reflect current progress. |
| Reason | Azure DevOps updates this automatically when you change the State. Each State has a default Reason. |
| Area | Choose the area path associated with the product or team, or leave it blank until planning. To edit area paths, see Define area paths and assign to a team. |
| Iteration | Choose the sprint or iteration for the work, or assign it later during planning. To edit iterations, see Define iteration paths (sprints) and configure team iterations. |
Track active, open, resolved, or closed work items
Workflow states describe how a work item moves from creation to closure. They also determine whether a work item appears on a backlog or board; see How workflow category states are used in Azure Boards backlogs and boards.
The User Story (Agile) uses states such as New, Active, Resolved, Closed, and Removed. The included images illustrate the typical state progressions for User Stories (Agile), Issues (Basic), Product Backlog Items (Scrum), and Requirements (CMMI).
Workflow states: User Story, Agile process
Note
- A work item can exist in only one state at a time.
- When all work is complete, set the work item State to Closed.
- Use boards and the Sprint Taskboard to view and update workflow states with drag and drop. See Start using your board and Update and monitor your Taskboard.
- Depending on the
View Options you select, work items in Closed or Completed states might not appear on the backlog. - The Removed state prevents a work item from appearing on the backlog. For details, see Move, change, or delete work items.
- Query work items by State and other fields to list work in progress, resolved, or completed items. See Query by assignment or workflow changes.
Assign work
You can assign a work item to only one person at a time. The Assigned To field stores the identity of a project member. In the work item form, open Assigned To to select a project member or start typing a name to narrow results.
Note
- Assign work only to users who are added to a project or team.
- A work item can have only one assignee at a time. If multiple people share work, create separate work items for each responsible person.
- The identity drop-down shows names you recently selected.
- Assign multiple work items at once from the backlog or query results. See Bulk modify work items.
- For details about identity fields, see Query by assignment or workflow changes.
When your account connects to Microsoft Entra ID or Active Directory, Azure DevOps synchronizes identity fields such as Activated By, Assigned To, Closed By, Created By, and Resolved By.
To grant project access, add security groups defined in Microsoft Entra ID or Active Directory. For details, see Add or delete users using Microsoft Entra ID or Set up groups for on-premises Azure DevOps Server deployments.
Use work item templates to quickly complete forms
Work item templates let you quickly create work items with prepopulated field values. For example, create a task template that sets Area Path, Iteration Path, and discipline whenever you create that task. See Use templates to add and update work items.
Follow, Refresh, Revert, and Actions menu
The Follow, Refresh, Revert changes, and Actions menu controls appear on all work item forms.
- Choose Follow to get updates when someone changes the work item. For details, see Follow changes made to a user story, bug, or other work item or pull request.
- Choose
Refresh to update the form with the latest changes someone made while you had the work item open.
- Choose
Revert changes to undo any edits you made to the form.
- Use the Actions menu for tasks such as:
- New linked work item
- Change type
- Move to team project
- Create copy of a work item
- Send email with work item
- Delete
- Templates
- New branch...
- Customize
Note
Some menu options might not appear depending on your permissions. Marketplace extensions or process customizations can add extra options.
Discussion control
Use the Discussion control to add and review comments about the work. The rich text editor toolbar appears when you focus the entry box. Each comment records an entry in the History field. For details, see View and add work items. To query Discussion or History, see Query work item history and discussion fields.
Deployment, Development, and Related Work controls
The Deployment, Development, and Related Work controls appear in most work item forms.
The Deployment control shows deployment stages and status for a feature or user story, and provides navigation to release runs. See Link work items to deployments.
The Development control surfaces branches, commits, pull requests, and builds related to the work item so you can trace development. See Drive Git development from a work item.
The Related Work control shows linked work items and lets you add or remove links quickly. See Link user stories, issues, bugs, and other work items.
History, Links, and Attachment tabs
The 
History, 
Links, and
Attachments tabs support auditing, traceability, and sharing. Use them to review change history, manage links, and attach files.
History: Review changes made to the work item
The
History tab records changes to a work item over time. Each change to common fields, rich-text fields, Discussion entries, links, or attachments creates a history entry.
The state-change history diagram appears first. Select Show all to see the full state history.
Select an entry in the left pane to view change details. For more information, see Query work item history and discussion fields.
Links: Link work items to other work items or objects
From the
Links tab, add, remove, or view work items and other objects linked to the current work item.
For more, see Link work items to other objects and Link type reference.
Attachments: Attach files to a work item
From the
Attachments tab, add, remove, or view files and images attached to the work item. You can add up to 100 attachments; attachments are limited to 60 MB each. For more, see Share information within work items and social tools.
Track work in the web portal
Add and update work items from the web portal. For an overview of other clients, see Tools and clients that connect to Azure DevOps. Use the web portal to perform the tasks listed here.
- Work items: Use to quickly find work items assigned to you or filter work items based on other criteria, such as work items that you follow, that you're mentioned in, or that you viewed or updated.
- Boards: Use to implement Kanban practices, update the State, and visualize the flow of work for a team.
- Backlogs: Use to plan, prioritize, and organize the work for a team to do within a product or portfolio backlogs.
- Sprints: Use to plan work for a team to perform during a sprint.
- Queries: Use to define a set of filter criteria to list work items for the purposes of sharing with others, performing bulk updates, or import/export operations.
- Delivery Plans: Use to review the schedule of stories or features your teams plan to deliver. Plans show scheduled work items defined that are assigned to sprints (iteration path) of selected teams against a calendar view.
- Work items: Use to quickly find work items assigned to you or filter work items based on other criteria, such as work items that you follow, that you're mentioned in, or that you viewed or updated.
- Boards: Use to implement Kanban practices, update the State, and visualize the flow of work for a team.
- Backlogs: Use to plan, prioritize, and organize the work for a team to do within a product or portfolio backlogs.
- Sprints: Use to plan work for a team to perform during a sprint.
- Queries: Use to define a set of filter criteria to list work items for the purposes of sharing with others, performing bulk updates, or import/export operations.
Work item types to track testing, reviews, and feedback
In addition to backlog/board types, Azure Boards provides work item types for testing, reviews, and feedback. The following table lists these types and typical uses:
| Category and Work item type | Used to track specified types of work |
|---|---|
| Code Review Request | Tracks a code review request against code maintained in a TFVC repository. See Day in the life of a Developer. |
| Code Review Response | A response for each reviewer who provides review comments. |
| Feedback Request | Tracks feedback requests generated through the feedback form. See Get feedback. |
| Feedback Response | Creates a response for each person who provides feedback through the Microsoft Feedback Client. See Get feedback. |
| Shared Step | Use shared steps to repeat tests with different data. |
| Shared Parameter | Define parameters for running manual test cases. See Repeat a test with different data. |
| Test Case | Define manual tests. See Create test cases. |
| Test Plan | Group test suites and test cases. See Create test plans and test suites. |
| Test Suite | Group test cases into testing scenarios within a test plan. See Create test plans and test suites. |
Required permissions and access
Members of the Contributors group can use most features under the Boards hub. To add users to a project, see Add users to a project or team.
The following table summarizes permissions that affect a member's ability to view and edit work items.
| Level | Permission |
|---|---|
| Area path | View work items in this node |
| Area path | Edit work items in this node |
| Project | Create tag definition |
| Project | Change work item type |
| Project | Move work items out of this project |
| Project | Delete and restore work items |
| Project | Permanently delete work items |
Users with Basic access have full access to work tracking features. Stakeholder access limits certain features. For details, see Set permissions and access for work tracking and Stakeholder access quick reference.