Edit

Share via

Customize your work tracking experience

  • Article

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

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:

  • 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.
  • 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.

Project-level shared resources

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:

People picker and identity fields

  • 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.

Screenshot of people picker Assigned To field.

For more information, see the following articles:

Organization-level process customization

Collection-level process customization

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.

Feature

Inheritance

Hosted XML

On-premises XML

WYSIWYG editing

✔️

Create inherited custom processes, Inherit changes in system processes (Agile, Basic, Scrum, CMMI)

✔️

Create custom process templates (see note 1)

✔️

✔️

Updated process changes automatically apply to all projects referencing the process

✔️

✔️

Support for customizing fields, work item types, form layout, workflow, custom rules, backlog levels, custom controls, test management

✔️

✔️

✔️

Support for customizing link types, team fields, global workflow, and process configuration (see note 3)

✔️

Initial configuration of Area paths, Iteration Paths, work item queries, security groups, and permissions (see note 3)

✔️

✔️

Global lists

Picklists

(see note 2)

✔️

Update Microsoft field mappings using the TFSFieldMapping command-line tool (see note 4)

✔️

✔️

Use az boards command-line tools to edit projects and teams and list information

✔️

✔️

✔️

Use the witadmin command-line tools to list and export process information

✔️

✔️

✔️

Use the witadmin command-line tools to edit process information

✔️

Use the tcm fieldmapping command-line tool to list and export test case management mapping for resolution types, bug filing, and failure types.

✔️

REST API (read)

✔️

✔️

✔️

REST API (write)

✔️

✔️

(see note 5)

Notes:

  1. 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.
  2. 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.
  3. 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
    Or, you can use REST APIs.
    Or, you can use REST APIs or the Azure DevOps CLI command tool.
  4. Support for Office Project integration with Azure DevOps is deprecated and the TFSFieldMapping command isn't supported.
  5. Use the REST API to import and export process templates.

Choose the process model for your project collection

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.

Screenshot showing Create Team Project Collection wizard, Collection Name 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.

Customize the test experience

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.

Screenshot showing Test management work item types.

Less common customizations

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.

Backlog and board limits (Hosted XML, On-premises XML)

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.

XML 
<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="800" >
    . . .
</TaskBacklog>

Change field assignments (Hosted XML, On-premises XML)

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 work tracking tools

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:

Manage access

Permissions

Shared resources

More customization options

Choose from the following other customization options:

Next steps

Configure and customize Azure Boards