Customize your backlogs or boards (Inheritance process)

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

You can customize your backlogs to add more levels or add custom work item types to them. As shown below, we've added a third level portfolio backlog labeled Initiatives which tracks the custom Initiative work item type, and we've 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.

Changes made to the backlog levels

Your project defines two portfolio backlogs: Features and Epics. However, if you need one or more additional portfolio backlogs, you can add them.

Important

This article applies to Azure DevOps Services and Azure DevOps Server 2019 and later versions. To customize any project defined on a collection for TFS 2018 or earlier, see On-premises XML process model.

Important

You can only use the Inheritance process model for projects defined on a project collection configured to support the Inheritance process model. 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. To learn more, see Customize work tracking, Choose the process model for your project collection.

To customize any project defined on a collection for TFS 2018 or earlier, see On-premises XML process model.

Portfolio backlogs are useful for organizing your backlog under various business initiatives and user scenarios. When you organize your backlogs into portfolios, you can gain a hierarchical view of the work defined in lower-level backlogs, including work in progress across several teams. Program managers can track the status of those backlog items of interest and drill down to ensure that all work is represented.

To learn more about what you can customize, see About process customization and inherited processes.

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


What you can't customize

  • You can't remove an inherited portfolio level from the product (but you can rename the portfolio level and you can disable an inherited work item type)
  • You can't insert a backlog level within the existing set of defined backlogs
  • You can't reorder the backlog levels
  • You can't add a work item type to two different backlog levels
  • You can't create a custom task backlog 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.
  • 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 the portfolio level and you can disable an inherited work item type)
  • You can't insert a backlog level within the existing set of defined backlogs
  • You can't reorder the backlog levels
  • You can't add a work item type to two different backlog levels
  • You can't create a custom task level, although you can add custom work item types 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.

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, you can by editing 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 which haven't been 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

Web portal, Process, Backlog levels, Other work item types section, Agile process

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 are assigned to a particular backlog level.

Web portal, Process, Backlog levels, Edit backlog level dialog

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 work item type to a backlog level, the following fields are added to the work item type 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 its 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 in Sprint burndown and capacity charts.

Prerequisites

Prior to customizing a process, we recommend that you review Configure and customize Azure Boards, which provides guidance on how to customize Azure Boards to meet your business needs. For a description of the different backlogs and boards, see Tasks supported by Backlogs, Boards, Taskboards, and Plans.

Open Settings>Process

You create, manage, and make customizations to processes from Organization settings>Process.

  1. Choose the Azure DevOps logo to open Projects. Then choose Organization settings.

    Open Projects>Organization settings.

  2. Then, choose Process.

    Then, choose Process.

    Important

    If you don't see Process, then you're working from TFS-2018 or earlier version. The Process page isn't supported. You must use the features supported for the On-premises XML process model.

You create, manage, and make customizations to processes from Collection Settings>Process.

  1. Choose the Azure DevOps logo to open Projects. Choose the project collection whose processes you want to customize, and then choose Collection Settings.

    Open Projects>Organization settings

  2. Then, choose Process.

    Then, choose Process.

You create, manage, and make customizations to processes from Admin settings>Process.

  1. Choose the Azure DevOps logo to open Projects. Then choose Admin settings.

    Open Project>Organization settings.

  2. Then, choose Process.

    Then, choose Process.

Note

As you customize an inherited process, all projects that use that process are updated automatically to reflect the customizations. For this reason, we recommend that you create a test process and test project when you have a number of customizations to make in order to test the customizations prior to rolling them out to your organization. To learn more, see Create and manage inherited processes.

Add or edit portfolio backlogs

The Agile, Scrum, and CMMI system processes defines 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 work item type when adding or editing a portfolio backlog, or you can choose a work item type you've previously added. Only those work item types that don't belong to another backlog level appear for selection.

Add a portfolio backlog

You can add a portfolio backlog and custom work item type following these steps.

  1. From the Backlog levels page, choose New top level portfolio backlog.

    Web portal, Admin context, Process page, select Process

  2. Name the backlog level, select the backlog level color, and add the work item type to associate with this level. Click Add.

    Web portal, Add a portfolio backlog dialog, Add new work item type

    Web portal, Add a portfolio backlog dialog, Add new work item type

  3. If you are 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.

    Web portal, Add a portfolio backlog dialog, Save changes.

    Web portal, Add a portfolio backlog dialog, Save changes

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.

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 are not deleted or affected in any way.

Deleting a backlog level removes the backlog and board associated with the level.

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

Here, we've 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.

On Edit backlog, Stories and Tickets is entered in Name, and there is a list of work item types for this backlog level.

Here, we've renamed the backlog, added Customer Ticket, and changed the default type to Customer Ticket.

Example of renaming the backlog, adding Customer Ticket, and changing 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.

Here, we've added the Ticket work item type which is tracked along with tasks.

Example of adding the Ticket work item.

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.

Note

You can review changes made to an inherited process through the audit log. To learn more, see Access, export, and filter audit logs.