Understand how work items are used to track user stories, issues, bugs, features, and epics

Azure Boards | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

You can use work items to track anything you need to track. Each work item represents an object stored in the work item data store. Each work item is based on a work item type and is assigned an identifier which is unique within an organization or project collection. The work item types available to you are based on the process used when your project was created.

In a nutshell:

Work item types (WITs)

To track different types of work, different WITs are defined. The WITs available to you differ depending on the process or process template used to create your project.

For example, the following WITs are available to you when you choose the Agile process.

Agile process, WITs used to plan and track

Note

The WITs available to you depend on the process chosen to create your project—Agile, Scrum, or CMMI. The items in your backlog may be called user stories, product backlog items (PBIs), or requirements. All three are similar: they describe the customer value to be delivered and the work to be performed.

To learn more about processes and process templates, see Choose a process.

Work item form

Each work item supports tracking data contained in work item fields. Also, it captures changes as updates are made within the History field and comments made in the Discussion section. To learn more about each field, see Work item field index. To learn about the different tabs and sections of the form, see Work item form controls.

Each work item supports tracking data contained in work item fields. Also, it captures changes as updates are made within the History field. To learn more about each field, see Work item field index.

Each form contains a number of controls as shown below and described in Work item form controls.

Work item form to track features or user stories

The new form and its corresponding features are available from the web portal. The new form is automatically available when you add projects to a new collection. For existing projects, an admin is required to enable the new form. To learn about the different tabs and sections of the new form, see Work item form controls.

New web form

The new web form provides a number of experiences not provided with the old web form. To learn more, see New work item experience.

Work item form to track features or user stories

Old web form

Work item form to track features or user stories


Work item form to track features or user stories

Track work in the web portal

You can add and update work items from the web portal. To track work using other clients, see Best tools for adding, updating, and linking work items .

Web portal and clients that support tracking work items

You can add and update work items from the web portal and various clients. For an overview of all clients that connect to your project, see Tools and clients that connect to Azure DevOps Services and TFS.

Web portal

Use the web portal to accomplish the following tasks.

Note

Your web portal uses either the New navigation or Previous navigation user interface. Choose the New navigation tab if the New Navigation feature is enabled. You'll see a vertical sidebar along with other navigational features when New Navigation has been enabled for the signed-in user or the organization. Choose Previous navigation when you see a top-level, blue-bar—indicating that New navigation isn't enabled. For more information, see Web portal navigation.

Note

Choose the New navigation tab for guidance. Azure DevOps Server 2019 supports the New Navigation user interface. For more information, see Web portal navigation.

Note

Choose the Previous navigation tab for guidance. TFS 2018 and earlier versions only support the previous navigation user interface. For more information, see Web portal navigation.

  • Work items: Use to quickly find work items assigned to you or pivot 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 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 specific time frame referred to as a sprint.
  • Queries: Use to define a set of filter criteria to list work items for the purposes of sharing with others or performing bulk updates.
  • 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. Requires installation of the Delivery Plans extension.

Choose the Previous navigation tab for guidance. TFS 2018 and earlier versions only support the previous navigation user interface. For more information, see Web portal navigation.

Assign work items to a project member

You can only assign a work item to one person at a time. The Assigned To field is a person-name field designed to hold an user identity recognizable by the system. Within the work item form, choose the Assigned To field to select a project member. Or, you can begin typing the name of a project member to quickly focus your search to a select few.

Web work item form, Assign to field

Anyone who has write access to a project can assign work items, including users with Basic and Stakeholder access.

Note the following:

  • You can assign a work item only to users that have been added a project or team
  • You can assign a work item to one and only one user at a time. If work is split across two or more users, then you should consider creating additional work items that you'll assign to each user responsible for the work to be completed
  • Over time, the drop-down menu of person-name fields will display the names you have most recently selected
  • Some drop-down menus that support assignment from a team backlog or board are automatically limited to users assigned to the team
  • The system shows the display name and adds the user name when required to disambiguate identical display names
  • You can assign several work items at once from the backlog or query results, see Bulk modify work items for details.

Integration with Azure Active Directory

When your system is configured with Azure Active Directory (Azure AD), then the system will synchronize person-name fields with these directories. Person-name fields include Activated By, Assigned To, Closed By, Created By, and Resolved By.

You can grant access to a project by adding security groups that you created in Azure AD or by adding accounts to existing or custom groups defined from the collection setting Security pages. To learn more, see Access with Azure Active Directory (Azure AD).

Integration with Active Directory

When TFS is configured with Active Directory (AD), then TFS will synchronize person-name fields with these directories. Person-name fields include Activated By, Assigned To, Closed By, Created By, and Resolved By.

You can grant access to a project by adding security groups that you created in AD or by adding accounts to existing or custom groups defined from the collection setting Security pages. To learn more, see Set up groups for use in TFS deployments.

Note

To minimize the list of names that appear in the drop-down menus of person-name fields, you can scope the field to only those groups that you want to appear in the menu. You do this by adding one or more of the following child elements to the FIELD definition in the work item type definition: ALLOWEDVALUES, PROHIBITEDVALUES, and VALIDUSER. For details, see Apply a field rule.

Assign work items to a sprint

To schedule work items to be worked on during a specific time period, you assign the Iteration Path. First, you define the Iteration Paths for use in the project, and then each team selects the Iteration Paths that they'll use. To learn more, see Assign work to sprints.

Track bugs as requirements or tasks

Many Scrum teams treat bugs the same as any backlog item or user story. Others see bugs as work that belongs to implementing a story, and therefore treat them as a task. Bugs, like product backlog items (PBIs) and user stories, represent work that needs doing. So, should you track your bugs along with other items in the product backlog items or as tasks linked to those backlog items? How does your team estimate work?

Based on how your team answers these questions, they can choose how they want to track bugs from one of these three choices. To change the team setting, see Show bugs on backlogs and boards.

For an overview of all team settings, see Manage teams and configure team tools.

Find or list work items

You can use the search box to perform an adhoc search to find specific work items based on select field criteria. Or, you can create a query to perform a managed search which will list work items based on your query criteria. With managed searches you can perform a number of other tasks, such as to triage work items, create a trend or status chart and add to the dashboard, and more.

To learn more, see these topics:

Use work item templates to quickly fill in forms

With work item templates you can quickly create work items which have pre-populated values for your team's commonly used fields. For example, you can create a task template that will set the area path, iteration path, and discipline or activity whenever you use it to create a task.

To learn more, see Use templates to add and update work items.

Once you have a template defined, you can share it via email or a dashboard.

Customize a WIT

You can add or modify the fields contained within a WIT or add a custom WIT. To learn more, see Customize an inheritance process.

You can add or modify the fields contained within a WIT or add a custom WIT. To learn more, see Customize the On-premises XML process model.

Required permissions and access

As a member added to the Contributors group of a project, you can use most features provided under Boards or Work. Users with Basic access have full access to all features. Users with Stakeholder access are limited to certain features. For details, see Work as a Stakeholder.

To learn more about permissions and access, see Permissions and access for work tracking and About access levels.

To add users to a project, see Add users to a project or team.

Try this next