title | titleSuffix | description | ms.service | ms.custom | ms.assetid | ms.author | author | ms.topic | monikerRange | ms.date |
---|---|---|---|---|---|---|---|---|---|---|
Customize your work tracking experience |
Azure DevOps |
Guide to configuring and customizing work tracking features. |
azure-devops-boards |
process |
D1B44480-F88B-4F35-927A-11ADFBCBAA23 |
chcomley |
chcomley |
overview |
<= azure-devops |
06/05/2024 |
[!INCLUDE version-lt-eq-azure-devops]
As you plan and track your project, consider configuring a feature or customizing your experience to align with your team's tracking requirements. The approach for customizing projects, which affects all teams, depends on the process model you’re using.
This article gives you an overview of the customizations available and how they vary across the three process models. For specific guidance on customizations to support business decisions, Configure and customize Azure Boards. For more information, see What is Azure Boards? and About work items.
You can customize at the following levels of work tracking:
::: moniker range="azure-devops"
- Project-level shared resources: Define area and iteration paths which teams select to configure their backlogs and boards. Shared queries and work item tags are more objects that once defined can be shared across the project.
- Team assets or tools: Each team can configure their specific tools, such as backlogs, boards, and dashboards. For more information, see About teams and Agile tools.
- Project and object-level permissions: Manage access to work tracking tools, which include setting permissions for objects and the project and assigning users or groups to specific access levels.
- Organization-level process customization: Customize the fields, work item types, and backlogs and boards available to all teams. ::: moniker-end
::: moniker range="< azure-devops"
- Project-level shared resources: Define area and iteration paths which teams select to configure their backlogs and boards. Shared queries and work item tags are more objects that once defined can be shared across the project.
- Team assets or tools: Each team can configure their specific tools, such as backlogs, boards, and dashboards. For more information, see About teams and Agile tools.
- Project and object-level permissions: Manage access to work tracking tools, which include setting permissions for objects and the project and assigning users or groups to specific access levels.
- Collection-level process customization: Customize the fields, work item types, and backlogs and boards available to all teams.
::: moniker-end
Each project provides many shared resources that support all teams within the project. You configure these features through the user interface or the admin context of the web portal. For more information, see the following articles:
- About area and iteration paths
- Set area paths
- Change the pick list for an iteration path
- Create and edit queries
- Add tags to work items
- The Assigned To and other Identity fields are supported by the people picker feature.
- When you choose the Assigned To field within a work item form, the people picker is activated.
- To select a user, start entering their name and search until you find a match.
- Previously selected users appear automatically in the list.
- For organizations using Microsoft Entra ID or Active Directory, people pickers allow searching all users and groups added to the AD (not just ones added to a specific project).
- To limit the scope of identities available for selection to project-specific users, use the Project-Scoped Users group.
- Custom rules can further restrict the values available for Identity fields within a work item.
For more information, see the following articles:
- Add Active Directory / Microsoft Entra users or groups to a built-in security group. ::: moniker range="azure-devops"
- Limit identity search. ::: moniker-end
::: moniker range="azure-devops"
::: moniker-end
::: moniker range="< azure-devops"
::: moniker-end
Your project defines the work item types (WITs) available for tracking work and configures Agile tools. It specifies user stories, tasks, bugs, and the data fields used to capture information. Customized objects are shared across teams within the project.
Note
The method you use to customize work tracking depends on the process model you subscribe to:
- Inheritance: Supports WYSIWYG customization, available for Azure DevOps Services, Azure DevOps Server 2019, and Azure DevOps Server 2020.
- Hosted XML: Supports customization through import/export of process templates, available for a select number of customers of Azure DevOps Services who have opted into this model.
- On-premises XML: Supports customization through import/export of XML definition files for work tracking objects and is available for all on-premises deployments.
The following table summarizes the differences between the three supported process models. For definitions of the main work tracking objects, see Agile glossary. For links to customization articles, see Quick reference index for Azure Boards settings.
:::row::: :::column span="3"::: Feature :::column-end::: :::column span="1"::: Inheritance :::column-end::: :::column span="1"::: Hosted XML :::column-end::: :::column span="1"::: On-premises XML :::column-end::: :::row-end:::
:::row::: :::column span="3"::: WYSIWYG editing :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1":::
:::column-end::: :::column span="1":::
:::row::: :::column span="3"::: Create inherited custom processes, Inherit changes in system processes (Agile, Basic, Scrum, CMMI) :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1":::
:::column-end::: :::column span="1":::
:::row::: :::column span="3"::: Create custom process templates (see note 1) :::column-end::: :::column span="1":::
:::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::row-end:::
:::row::: :::column span="3"::: Updated process changes automatically apply to all projects referencing the process :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1":::
:::row::: :::column span="3"::: Support for customizing fields, work item types, form layout, workflow, custom rules, backlog levels, custom controls, test management :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::row-end:::
:::row::: :::column span="3"::: Support for customizing link types, team fields, global workflow, and process configuration (see note 3) :::column-end::: :::column span="1":::
:::column-end::: :::column span="1":::
:::row::: :::column span="3"::: Initial configuration of Area paths, Iteration Paths, work item queries, security groups, and permissions (see note 3) :::column-end::: :::column span="1":::
:::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::row-end:::
:::row::: :::column span="3"::: Global lists :::column-end::: :::column span="1"::: Picklists :::column-end::: :::column span="1"::: (see note 2) :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::row-end:::
::: moniker range="azure-devops"
:::row:::
:::column span="3":::
Use az boards
command-line tools to edit projects and teams and list information
:::column-end:::
:::column span="1":::
✔️
:::column-end:::
:::column span="1":::
✔️
:::column-end:::
:::column span="1":::
✔️
:::column-end:::
:::row-end:::
::: moniker-end
:::row:::
:::column span="3":::
Use the witadmin
command-line tools to list and export process information
:::column-end:::
:::column span="1":::
✔️
:::column-end:::
:::column span="1":::
✔️
:::column-end:::
:::column span="1":::
✔️
:::column-end:::
:::row-end:::
::: moniker range="< azure-devops"
:::row:::
:::column span="3":::
Use the witadmin
command-line tools to edit process information
:::column-end:::
:::column span="1":::
:::column-end::: :::column span="1":::
::: moniker-end
::: moniker range="< azure-devops"
:::row:::
:::column span="3":::
Use the tcm fieldmapping
command-line tool to list and export test case management mapping for resolution types, bug filing, and failure types.
:::column-end:::
:::column span="1":::
:::column-end::: :::column span="1":::
::: moniker-end :::row::: :::column span="3"::: REST API (read) :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::row-end:::
:::row::: :::column span="3"::: REST API (write) :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1"::: ✔️ :::column-end::: :::column span="1"::: (see note 5) :::column-end::: :::row-end:::
Notes:
- A process determines the building blocks used to track work. A process template specifies an interdependent-related set of XML definition files that provide the building blocks and initial configuration for tracking work and other functional areas.
- Hosted XML customization supports adding and updating global lists with a process update (subject to limits on maximum size of each list). For more information, see Work tracking object limits.
- The Inherited process model doesn't support customization of the following features available with customization of process templates. Instead, you customize these areas within the web portal on a project-by-project basis.
- Area and iteration paths
- Work item queries
- Security groups and permissions
- Permissions and access to functional areas such as version control and build ::: moniker range="< azure-devops" Or, you can use REST APIs. ::: moniker-end ::: moniker range="azure-devops" Or, you can use REST APIs or the Azure DevOps CLI command tool. ::: moniker-end
- Support for Office Project integration with Azure DevOps is deprecated and the
TFSFieldMapping
command isn't supported. - Use the REST API to import and export process templates.
::: moniker range="< azure-devops"
For Azure DevOps Server 2019 and Azure DevOps Server 2020, you can choose between XML (On-premises XML process model) and Inheritance (Inheritance process model), as shown in the following dialog.
Important
The process choice you make is irreversible. Once it's set up, you can only customize work tracking objects based on the selected model. Also, existing project collections using the On-premises XML process model can't get migrated to the Inheritance process model.
For more information, see Manage project collections.
::: moniker-end
Several work item types support the test experience within the web portal Test pages and Test Manager client.
- For an Inherited process, you can customize the following work item types as you would any other work item type:
- Test Plan
- Test Suite
- Test Case
- For an On-premises XML process, you can customize all test-related work item types, including:
- Test Plan
- Test Suite
- Test Case
- Shared Steps
- Shared Parameters
The following example shows the supported link relationships.
::: moniker range="< azure-devops" For more information, see the following articles:
- Test configurations and test variables
- Failure types
- Define the initial test management configuration (process template)
- Query based on build and test integration fields ::: moniker-end
You can only perform the following customizations when working with the Hosted XML or On-premises XML process models. Customizations made to process configuration apply to all teams within a project.
To limit the display load time to acceptable parameters, the task board is restricted to a maximum of 1,000 work items. For details, see Process configuration XML element reference.
You can increase this value up to a maximum of 1500 by specifying a value for the workItemCountLimit
attribute of the TaskBacklog element. For details, see Process configuration XML element reference.
[!div class="tabbedCodeSnippets"]
<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="800" > . . . </TaskBacklog>
You can change the work item fields that are used in calculating capacity, burndown charts, forecasting, and velocity. Any change you make to one of the default assignments should correspond to a change made to the WIT used to define and capture information for that value.
For example, if you change the refname
assigned to type="Activity"
then you should include the same field in the WIT definition assigned to the Task Category that captures the activity information. For details, see Process configuration XML element reference.
The fields you assign are used by the following tools:
Tool | Field type |
---|---|
Task board, capacity tools, sprint burndown | Remaining work |
Product and portfolio backlogs | Backlog priority |
Velocity and forecast | Effort (maps to Story Points, Effort, or Size) |
Task board, capacity tools | Remaining work |
Capacity tools | Activity (Task Activity or Discipline) |
Manage access to specific features through permission settings. When you add user accounts to your team, they're automatically added to the Contributor group. They then have access to most of the features they'll need to contribute to code, work tracking, builds, and test. However, the Contributor group doesn't allow users to create shared queries or to add area or iteration paths. You have to grant these permissions separately.
You can manage access with the following permission settings:
- When you add user accounts to your team, they’re automatically added to the Contributor group.
- The Contributor group provides access to most features needed for contributing to code, work tracking, builds, and testing.
- But, the Contributor group doesn’t allow users to:
- Create shared queries
- Add area or iteration paths
- To grant these permissions separately, follow the appropriate steps.
- For a simplified overview of common default permissions and access assignments, see Permissions and access. If you’re new to managing permissions, explore Get started with permissions, access, and security groups, Permission inheritance and security groups.
To manage access to specific features, see the following articles:
:::row:::
:::column span="1":::
Manage access
- About access levels
- Add team members (Azure DevOps Services)
- Change access levels (on-premises deployments)
- Add team members (on-premises deployments)
:::column-end:::
:::column span="1":::
Permissions
- Area path permissions
- Process permissions
- Work item query and folder permissions
- Dashboard permissions
- Delivery Plan permissions
- Tagging permissions
- Test permissions
:::column-end:::
:::column span="1":::
Shared resources
- Alerts
- Area paths
- Iteration paths
- Queries
- Tags
:::column-end:::
:::row-end:::
Choose from the following other customization options:
- Check out Marketplace extensions to see if there's a tool available for your purposes
- Develop your own extension
- Determine if a Service hook satisfies your needs
- Create your own tool using REST APIs
- Add a feature request to our Developer Community page.
[!div class="nextstepaction"] Configure and customize Azure Boards