Customize your backlogs or boards (Inheritance process)
- 5 minutes to read
Azure Boards | Azure DevOps Server 2019
You can customize your backlogs to add more levels or add custom work item types (WITs) to them. As shown below, we've added a third level portfolio backlog labeled Initiatives which tracks the custom Initiative WIT, 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.
Your project defines two portfolio backlogs: Features and Epics. However, if you need one or more additional portfolio backlogs, you can add them.
Important
To customize a project collection that uses the On-premises XML process model, available only for on-premises deployments, see On-premises XML process model. This article applies to Azure DevOps Services and Azure DevOps Server only.
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 has been 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 or remove an inherited WIT to or from a backlog, for example, you can't add the Issue WIT to the product backlog.
Prerequisites
- You must have an organization created in Azure DevOps Services. If you haven't created one yet, do that now.
- To create, edit, and manage processes, you must be a member of the Project Collection Administrators group, or have the corresponding permissions Create process, Delete process, Edit process, or Delete a field from organization set to Allow. See Set permissions and access for work tracking, Customize an inherited process.
- You must have selected the Inheritance process model for the project collection where the project is created.
- To create, edit, and manage processes, you must be a member of the Project Collection Administrators group, or have the corresponding permissions Create process, Delete process, Edit process, or Delete a field from organizaiton set to Allow. See Set permissions and access for work tracking, Customize an inherited process.
Open Settings>Process
You create, manage, and make customizations to processes from Organization settings>Process.
Choose the
Azure DevOps logo to open Projects. Then choose Organization settings.
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 Admin settings>Process.
Choose the
Azure DevOps logo to open Projects. Then choose Admin settings.
Then, choose Process.
Important
If you don't see Process, then the collection you've created is set to work with the On-premises XML process model. You must use the features supported for the On-premises XML process model.
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
Each process defines two default portfolio backlogs, Epics and Features; each is associated with their corresponding work item types, epics and features.
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
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. Click Add.
If you are associating only one work item type with the backlog, then click Save to save your changes. Otherwise, you can add more work item types as needed.
Edit, rename, or delete a portfolio backlog
Open the context menu of a portfolio backlog that you've added to edit, rename, or delete it. From the Backlog levels page, open the Add portfolio backlog dialog.
Note
You can't add an inherited WIT to any backlog level.
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.
Note
You can't remove the default, inherited WIT from the Epics or Features portfolio backlogs.
Edit or rename the requirement backlog
The Requirement backlog, also referred to as the product backlog, defines the WITs that appear on the product backlog and Kanban board. The default WIT for Agile is User Story; for Scrum, Product Backlog Item; and for CMMI, Requirement.
You can rename the backlog, change the color, add WITs, and change the default WIT. Open the Edit backlog dialog from the context menu for the Requirements backlog.
Here, we've renamed the backlog, added Customer Ticket, and changed the default type to Customer Ticket.
Note
You can't remove the default, inherited WIT from the Requirements backlog.
Edit the iteration backlog
The Iteration backlog, also referred to as the sprint backlogs, defines the WITs that are displayed on the sprint backlogs and task boards. The default WIT for all processes is Task.
For the iteration backlog, you can add WITs and change the default WIT. Open the Edit backlog dialog from the context menu for the Iteration backlog.
Here, we've added the Ticket WIT which is tracked along with tasks.
Note
You can't remove the default, inherited WIT from the Iteration backlog.
Related articles
Feedback
Loading feedback...