Customize backlogs and boards (Inheritance process)
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
In your project, you currently have two predefined portfolio backlogs: "Features” and “Epics." But, if your project requires more portfolio backlogs, you can create them.
Important
The Inheritance process model is available for projects configured to support it. If you’re using an older collection, check the process model compatibility. If your on-premises collection is configured to use the on-premises XML process model, you can only use that process model to customize the work tracking experience. For more information, see Choose the process model for your project collection.
Benefits of portfolio backlogs:
- Organizing work: Portfolio backlogs allow you to organize work based on business initiatives, user scenarios, or other relevant criteria.
- Hierarchical view: By structuring backlogs into portfolios, you gain a hierarchical view of work, which includes items defined in lower-level backlogs (such as user stories, features, or tasks).
- Cross-team visibility: Program managers can track the status of backlog items across multiple teams. They can drill down to ensure that all work is adequately represented.
For more information, see About process customization and inherited processes.
In the following example, we added a third level portfolio backlog labeled Initiatives, which tracks the custom Initiative work item type. We also renamed the product backlog to Stories and Tickets to indicate that we not only track User Stories, but also Customer Tickets on the product backlog.
Note
You can't add an inherited work item type to any backlog level. For example, you can't add the Issue or Impediment work item type to the product backlog.
Supported 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 custom portfolio backlogs for a total of five portfolio backlogs.
Backlog types
Customization support
Inherited backlogs
Custom portfolio backlogs
Unsupported customizations:
- Removing an inherited portfolio level:
- While you can’t directly remove an inherited portfolio level from a product, you have a couple of options:
- Rename the portfolio level: You can rename the inherited portfolio level to better suit your needs.
- Disable an inherited WIT: If the inherited portfolio level includes WITs that you don’t want to use, you can disable them. This action prevents teams from creating new work items of those types.
- While you can’t directly remove an inherited portfolio level from a product, you have a couple of options:
- Inserting a backlog level:
- You can't insert a new backlog level within the existing set of defined backlogs. The predefined backlog levels are typically fixed (for example, Epics, Features, User Stories, Tasks), and you can’t add custom ones in between.
- Reordering backlog levels:
- Unfortunately, you can't reorder the backlog levels. They usually follow a predefined hierarchy, and changing their order isn’t supported.
- Adding a WIT to multiple backlog levels:
- Each WIT can only belong to one backlog level. You can't add a WIT to two different backlog levels simultaneously.
- Creating a custom task backlog level:
- Although you can't create a custom task-specific backlog level, you can still add custom WITs to the iteration backlog. For example, you could create a custom WIT called "Enhancement" or "Maintenance" and associate it with the iteration backlog.
- Managing bugs:
- The Bug WIT doesn’t belong to any specific backlog level by default. Instead, each team can decide how they want to manage bugs. You can choose to show bugs on backlogs and boards or handle them separately.
- Adding or removing an inherited WIT from a backlog:
- You can't directly add or remove an inherited WIT to or from a backlog. For instance, adding the "Issue" WIT to the product backlog isn’t supported.
- However, you can:
- Rename the portfolio level: If the inherited portfolio level includes WITs you don’t want to use, consider renaming it to better suit your needs.
- Disable an inherited WIT: If there are inherited WITs that you want to exclude, you can disable them. This action prevents teams from creating new work items of those types.
- Removing an inherited portfolio level:
- While you can’t remove an inherited portfolio level from a product, you have a couple of options:
- Rename the portfolio level: Give it a more fitting name.
- Disable inherited WITs: Prevent teams from using specific inherited WITs.
- While you can’t remove an inherited portfolio level from a product, you have a couple of options:
- Inserting a backlog level:
- Unfortunately, you can't insert a new backlog level within the existing set of defined backlogs. The predefined backlog levels remain fixed (for example, Epics, Features, User Stories, Tasks).
- Reordering backlog levels:
- Backlog levels typically follow a predefined hierarchy, and changing their order isn’t supported. You can't reorder them.
- Adding a WIT to multiple backlog levels:
- Each WIT (for example, Bug, Task, User Story) can only belong to one backlog level. You can't add a WIT to two different backlog levels simultaneously.
- Creating a custom task level:
- Although you can't create a custom task-specific backlog level, you can still add custom WITs to the iteration backlog. For example, create a custom WIT called "Enhancement" or "Maintenance" and associate it with the iteration backlog.
- Managing bugs:
- The Bug WIT doesn’t belong to any specific backlog level by default. Instead, each team can decide how they want to manage bugs. You can choose to show bugs on backlogs and boards or handle them separately.
Note
Certain features require installation of Azure DevOps Server 2020.1 update. For more information, see Azure DevOps Server 2020 Update 1 RC1 Release Notes, Boards.
Add a system work item type to a backlog
If you want to track Issues or Impediments or other inherited work item types within a backlog or board, edit the corresponding backlog. The following table lists the available work item types you can add to a backlog.
Note
This feature requires Azure DevOps Server 2020.1 update or later version.
Process
Work item types
Agile
Issue
Scrum
Impediment
CMMI
Change Request, Issue, Review, Risk
Each Edit backlog level dialog automatically includes inherited and custom work item types that aren't assigned to other backlog levels. For example, unassigned Agile work item types are listed under the Other work item types section as shown in the following image
These same work item types, along with any custom work item types, appear in the Edit backlog level dialog of all backlog levels, until they get assigned to a particular backlog level.
Note
You can't remove the default, inherited work item type from any backlog level, but you can disable the corresponding work item type. For example, you can disable the User Story work item type for the Agile Requirement backlog as long as you have added another work item type to support that backlog.
Fields added to work item types
When you add a WIT to a backlog level, certain fields are automatically added to the WIT definition as hidden fields. These fields don't appear on the work item form but are essential for supporting specific Agile tool features.
Backlog level | Fields added | Description |
---|---|---|
Portfolio backlog | - Stack rank (Agile, CMMI) - Backlog Priority (Scrum) |
The Stack Rank and Backlog Priority fields capture the relative priority of work items as they get reordered on a backlog or board. For more information, see Behind the scenes: the Backlog Priority or Stack Rank field. |
Requirement backlog | - Stack Rank, Story Points (Agile) - Stack Rank, Size (CMMI) - Backlog Priority, Effort (Scrum) |
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. |
Iteration backlog | - Activity, Remaining Work, Stack Rank (Agile) - Discipline, Remaining Work, Stack Rank (CMMI) - Activity, Remaining Work, Backlog Priority (Scrum) |
Remaining Work is used in Sprint burndown and capacity charts. |
Prerequisites
Check out Configure and customize Azure Boards, which offers guidance on tailoring Azure Boards to align with your specific business requirements.
Organization requirement: Ensure you have an organization in Azure DevOps.
Permissions:
- Be a member of the Project Collection Administrators group.
- Have collection-level permissions such as Create process, Delete process, Edit process, or Delete a field from organization set to Allow.
- These permissions allow you to modify processes and fields within your organization.
Project process model requirement:
- Ensure that you have the Inheritance process model for the project collection where the project is created.
Permissions:
- Be a member of the Project Collection Administrators group.
- Have collection-level permissions such as Create process, Delete process, Edit process, or Delete a field from organization set to Allow.
- These permissions allow you to modify processes and fields within your organization.
Note
When you customize an inherited process, any projects using that process automatically reflect the customizations. To ensure a smooth transition, we recommend creating a test process and project, which allows you to test your customizations before you implement them organization-wide. For more information, see Create and manage inherited processes.
Add or edit portfolio backlogs
The Agile, Scrum, and CMMI system processes define two default portfolio backlogs, Epics and Features. Each is associated with their corresponding work item types, Epic, and Feature. The Basic process only defines the Epics backlog and Epic work item type. For more information, see About processes and process templates.
You can add a custom WIT or select one that you previously added. Keep in mind that only WITs not associated with another backlog level appear for selection.
Add a portfolio backlog
You can add a portfolio backlog and custom work item type following these steps.
Sign in to your organization (
https://dev.azure.com/{Your_Organization}
).Select
Organization settings.
Select Process.
Sign in to your collection (
https://dev.azure.com/{Your_Collection}
).Select Collection Settings or Admin settings.
Select Process.
From the Backlog levels page, choose
New top level portfolio backlog.
Name the backlog level, select the backlog level color, and add the work item type to associate with this level, and then select Add.
If you're associating only one work item type with the backlog, then choose Save to save your changes. Otherwise, you can add more work item types as needed.
Edit, rename, or delete a portfolio backlog
From the Backlog levels page, choose the
context menu of a portfolio backlog to edit, rename, or delete it.
Deleting a backlog level removes the backlog and board associated with the level for all teams, including customizations made to them. The work items defined with the associated work item types aren't deleted or affected in any way.
Note
You can't remove the default, inherited work item type from the Epics or Features portfolio backlogs. However, you can disable these work item types and that effectively removes them from the user interface.
Edit or rename the requirement backlog
The Requirement backlog, also referred to as the product backlog, defines the work item types that appear on the product backlog and board. The default work item type for Agile is User Story; for Basic, Issue; for Scrum, Product Backlog Item; and for CMMI, Requirement.
You can rename the backlog, change the color, add work item types, and change the default work item type. Open the Edit backlog dialog from the context menu for the Requirements backlog.
In the following example, we renamed the backlog, added Customer Ticket and Issue, and changed the default type to Customer Ticket. Check those boxes of the work item types to include on the backlog.
In the following example, we renamed the backlog, added Customer Ticket, and changed the default type to Customer Ticket.
Note
You can't remove the default, inherited work item type from the Requirements backlog. However, you can disable the work item type and that effectively removes it from the user interface.
Edit the iteration backlog
The Iteration backlog, also referred to as the sprint backlogs, defines the work item types that are displayed on the sprint backlogs and Taskboards. The default work item type for all processes is Task.
For the iteration backlog, you can add work item types and change the default work item type. Open the Edit backlog dialog from the context menu for the Iteration backlog.
In the following example, we added the Ticket work item type that is tracked along with tasks.
Note
You can't remove the default, inherited work item type from the Iteration backlog. However, you can disable the work item type and that effectively removes it from the user interface.