About process customization and inherited processes
Azure Boards | Azure DevOps Server 2019
To customize the work tracking system, you customize an inherited process through the administrative user interface for the organization. All projects that use an inherited process get the customizations made to that process. On the other hand, you configure your Agile tools—Backlogs, Sprints, Kanban boards, and Taskboard—for each team.
To customize an on-premises project or update XML definition files to support customization, see On-premises XML process model. This article applies to Azure DevOps Services and Azure DevOps Server 2019 only.
There are a number of customizations you can make. The primary ones are adding custom work item types (WITs) or modifying an existing WIT to add custom fields, modify the layout, or change the workflow.
System versus inherited processes
You'll see two types of processes:
- System processes —Scrum, Agile, and CMMI—which are locked from being changed.
- Inherited processes, which you can customize and that inherit definitions from the system process from which they were created. System processes are owned and updated periodically by Microsoft. Any updates made to a system process will automatically update your inherited process.
In addition, all processes are shared. That is, one or more projects can use a single process. Instead of customizing a single project, you customize a process. Changes made to the process automatically update all projects that use that process.
Once you've created an inherited process, you can customize it, create projects based on it, make a copy of it, and change existing projects to use it.
For example, as shown in the following image, you see a list of projects defined for the fabrikam organization. The second column shows the process used by each project. To change the customizations of the Fabrikam Fiber project, you need to modify the MyAgile process (which inherits from the Agile system process). Any changes you make to the MyAgile process will also update the Test Agile project. You can't customize the Scrum Project, on the other hand, until you change it to a process which inherits from Scrum.
Process name restrictions
Process names must be unique and 128 Unicode characters or less. Also, names can't contain the following characters:
To rename a process, open the … context menu for the process and choose Edit.
Inherited objects versus custom objects
Each inherited process you create inherits the WITs defined in the system process—Agile, Scrum, or CMMI. For example, the Agile process provides bug, task, user story, feature, epic, issue and test-related WITs.
You can add fields and modify the workflow and work item form for all inherited WITs that display on the Work Item Types page. If you don't want users to create a WIT, you can disable it. In addition, you can add custom WITs.
Fields defined in the system process appear with an inherited icon, indicating that you can make limited modifications to it in your inherited process.
Fields are defined for all projects and processes in the organization. That means that any custom field you defined for a WIT in one process can be added to any other WIT defined for another process.
|Field type||Customization support|
When adding custom fields, note the following limits:
- A maximum of 64 fields can be defined for each WIT
- A maximum of 512 fields can be defined per process
In addition, you can add an existing field to another WIT within the process. For example, you can add Due Date to the user story or bug WITs.
What you can't customize
- You can't change the field name or data type once you've defined it
- With regards to picklists, you currently can't perform these operations:
- Change the picklist of an inherited field, such as the Activity or Discipline field
- Change the picklist order, picklists display in alphabetic order
- Import or define a global list as supported by the Hosted XML and On-premises XML process models. To learn more, see Define global lists.
The following picklists are configured for each project and not customizable through an inherited process.
Picklists associated with person-name fields, such as Assigned To and Changed By, are managed based on the users you add to a project or team.
Can a field be renamed or its field type changed?
Renaming a field or changing the field type aren't supported actions.
However, you can change the label that appears for a field on the work item form from the Layout tab. When selecting the field in a query you need to select the field name and not the field label.
What is a field? How are field names used?
Each work item type is associated with 31 system fields and several more type-specific fields. You use work items to plan and track your project.
Each field supports tracking a piece of information about the work to perform. Values you assign to a field are stored in the work tracking data store which you can create queries to determine status and trends.
A work item field name uniquely identifies each work item field. Make sure your field names fall within these guidelines:
- Field names must be unique within the organization or project collection
- Field names must be 128 or fewer Unicode characters
- Field names can't contain any leading or trailing spaces, nor two or more consecutive spaces
- Field names must contain at least one alphabetic character
- Field names can't contain the following characters:
Because all fields are defined for the organization, you can't add a custom field with the same field name that already exists in the organization or was added to a WIT in another inherited process.
When you change a project to use an inherited process, you may find one or more Agile tools or work items appear in an invalid state. For example:
- If you make a field required, work items with that field undefined will show an error message. You'll need to resolve the errors to make additional changes and save the work item.
- If you add or remove/hide workflow states of a WIT that appears on the Kanban board, you'll need to update the Kanban board column configurations for all teams defined in the project.
Custom rules and system rules
Each WIT—bug, task, user story, etc.—has several system rules already defined. Some are simple, like making the Title field required or setting a default for the Value Area field. In addition, a number of system rules define actions to take when a workflow state changes.
For example, several rules exist to copy the current user identity under the following conditions:
- When a work item is modified, copy the user identity to the Changed By field
- When the workflow state changes to Closed or Done, copy the user identity to the Closed By field.
Predefined system rules will take precedent over any custom rule that you define which would overwrite it.
Custom rules provide support for a number of business use cases, allowing you to go beyond setting a default value for a field or make it required. Rules allow you to clear the value of a field, copy a value into a field, and apply values based on dependencies between different fields' values.
With a custom rule, you can define a number of actions based on specific conditions. For example, you can apply a rule to support these types of scenarios:
- When a value is defined for Priority, then make Risk a required field
- When a change is made to the value of Release, then clear the value of "Milestone"
- When a change was made to the value of Remaining Work, then make Completed Work a required field
- When the value of Approved is True, then make Approved By a required field
- When a user story is created, make the following fields required: Priority, Risk, and Effort
You can't define a formula using a rule. However, you may find a solution that fits your needs via the TFS Aggregator (Web Service) Marketplace extension. See also Rollup of work and other fields.
For details on defining custom rules, see Add a rule to a work item type.
Here are your customization options for inherited and custom WITs.
|WIT type||Customization support|
- You can't add or remove an inherited WIT to or from a backlog
- You can't change the position of an inherited field within the form layout (however, you can hide the field in one area of the form and add it elsewhere in the form) - You can't remove the inherited portfolio level from the product (but you can rename them) - You can't change the name of a custom WIT. ### Work item form customizations You can make the following customizations to a WIT form.
|Group or page type||Customization support|
Layout and resizing
The web form layout is organized into three columns as shown in the image below.
If you only add groups and fields to the first two columns, then the layout reflects a two column layout. Likewise, if you only add groups and fields to the first column, then the layout reflects a one column layout.
The web form resizes depending on the width available and the number of columns in the layout. At maximum width, in most web browsers, each column within a page will display within its own column. As the display width decreases, each column resizes proportionally as follows:
- For three columns: 50%, 25%, and 25%
- For two columns: 66% and 33%
- For one column: 100%.
When the display width won't accommodate all columns, columns appear stacked within the column to the left.
You can customize the workflow of any WIT by hiding inherited states or adding custom states. By default, each WIT is defined with three or four workflow states. Inherited states differ based on the system process —Agile, Scrum, or CMMI—you chose from which to create your custom process.
Before adding a workflow state, review Workflow states and state categories to learn how workflow states are used to support several Agile tools.
|State types||Customization support|
The workflow states must conform to the following rules:
- At least one state must be defined for either the Proposed or In Progress state categories
- At a minimum, there must be at least two workflow states defined
What you can't customize
- You can't modify an inherited state (you can't change its name, color, or category), but you can hide it
- You can't modify the state assigned to the Completed state category for any WIT, custom or inherited
- You can't change the name of a custom state
- You can't change the order of states (states are listed in the order you add them within the States page, and they're listed alphabetically within the drop down list of a work item form)
- You can't specify a Reason for a state, instead, default reasons are defined such as Moved to state Triaged, Moved out of state Triaged
- You can't restrict transitions, all transitions are defined from any state to another state.
Backlog and board customizations
Backlogs and boards are essential Agile tools for creating and managing work for a team. The standard backlogs—product, iteration, and portfolio—inherited from the system process are fully customizable. In addition, you can add two custom portfolio backlogs.
|Backlog types||Customization support|
|Custom portfolio backlogs|
When you change the default WIT for a backlog level, it causes that WIT to appear by default in the quick add panel. For example, Customer Ticket appears by default in the following quick add panel for the product backlog.
What you can't customize
- You can't add or remove an inherited WIT to or from a backlog, for example, you can't add the Issue WIT to the product backlog
- You can't remove an inherited portfolio level from the product (but you can rename them)
- You can't insert a backlog level within the existing set of defined backlogs
- You can't reorder the backlog levels
- You can't create a custom task level, although you can add custom WITs to the iteration backlog
- You can't add the Bug WIT to any backlog level. Instead, the system allows each team to decide how they want to manage bugs. To learn more, see Show bugs on backlogs and boards.
Fields added to WITs associated with a backlog level
When you add a WIT to a backlog level, the following fields are added to the WIT definition as hidden fields (that is, they don't appear on the work item form) to support select Agile tool features.
|Backlog level||Fields added|
|Portfolio backlog||- Stack rank (Agile, CMMI)
- Backlog Priority (Scrum)
|Requirement backlog||- Stack Rank, Story Points (Agile)
- Stack Rank, Size (CMMI)
- Backlog Priority, Effort (Scrum)
|Iteration backlog||- Activity, Remaining Work, Stack Rank (Agile)
- Discipline, Remaining Work, Stack Rank (CMMI)
- Activity, Remaining Work, Backlog Priority (Scrum)
The Stack Rank and Backlog Priority fields capture the relative priority of work items as they are reordered on a backlog or board. For details on it's usage, see Behind the scenes: the Backlog Priority or Stack Rank field.
The Story Points, Size, and Effort fields capture the relative work required to complete a WIT assigned to the Requirement backlog. This value is used to compute velocity.
And, lastly, Remaining Work is used Sprint burndown and capacity charts.
For a list of limits placed on the number of fields, WITs, backlog levels, and other objects you can customize, see Work tracking object limits.
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.