Use backlogs to manage projects

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

With backlogs, you can quickly plan your project by adding user stories or requirements to your product backlog. Once you have your plan in place, you can start driving code development efforts.

If you're a project administrator, see Configure and customize Azure Boards, which shows you how to define area and iteration paths and customize your work item types. When you create a project or add a team, your backlog automatically gets created. Each team has access to their own product, portfolio, and sprint backlogs as described in About teams and Agile tools.

About backlogs

An Azure Boards backlog is a prioritized list of work items that guides your developments team's effort, helps manage project scope, and facilitates effective communication and collaboration through the software development lifecycle.

Use backlogs to do the following tasks:


For more information, see Backlogs, boards, and plans. In case you're not seeing the desired work items on your backlog or board, see Set up your backlogs and boards to configure them according to your preferences.

Product and portfolio backlogs

Backlogs present work items as lists. A product backlog represents your project plan, the roadmap for what your team plans to deliver. It also provides a repository of all the information you need to track and share with your team.

In Agile methodologies, a portfolio backlog allows you to group and organize your backlog into a hierarchy and displays high-level initiatives, epics, or projects that your organization plans to work on over a longer period of time. These initiatives are often too large or complex to fit within the scope of a single team's backlog, and they require coordination and planning at a higher organizational level.

Screenshot of Boards Backlogs.

Backlog configuration


How do I add a backlog or board? You don't add backlogs or boards. You add a team which is automatically configured with it's own set of backlogs and boards as described in About teams and Agile tools.

Each backlog is associated with a team and the team configuration settings determine the work items that appear on the team backlog. The team administrator does the following tasks for their team:

  • Select the Area Paths that are active for the team, only work items assigned to these area paths appear on the team's backlog
  • Set the default Area Path and Iteration Path used when defining work items from the team backlog
  • Select the Iteration Paths that are active for the team
  • Determine which backlog levels are active for the team
  • Define how bugs get treated, as requirements or as tasks

For more information, see the following articles:


Each team member has several tools to configure their backlog view: Expand/Collapse one level, Column Options, Backlog level selector, View options, and Filter toolbar. Options set for each backlog level are distinct and persist until changed. For more information, see Configure your backlog view.

Common backlog configurations for multiple teams

Question: Can you define a backlog configuration that multiple teams can subscribe to? Answer: No. Each team controls their own team settings and backlog configurations.

Because each user can configure their own Column Options and View Options, there's no way to configure a common backlog view for all teams. Also, there's no default column options that can be set for each team.

Because each user can configure their own Column Options and View Options, there's no way to configure a common backlog view for all teams. You can, however, define the default column options for all team members by editing the process configuration. To learn how, see Process configuration XML element reference, Set default columns.

Define work items and create your backlog

You build your project plan by creating a backlog of work items. These items represent the features, requirements, user stories, or other work to complete. Portfolio backlogs provide support for organizing work in a hierarchical fashion. They help track major product initiatives or scenarios that rely on many stories or requirements. Different types of work items help you track different types of work, such as user stories, tasks, bugs, issues, and more.

Define stories conceptual image of tasks.Organize backlog conceptual image of tasks.Manage bugs conceptual image of tasks.Manage issues conceptual image of tasks.

Backlog priority or stack rank order

The sequence of items on each backlog is determined according to where you've added the items or moved the items on the page. As you drag items within the backlog list, a background process updates the Stack Rank (Agile and CMMI processes) or Backlog Priority (Scrum process) fields. These fields are used by the system to track the relative ranking of items on the product, feature, epic, or other portfolio backlog. By default, these fields don't appear on the work item form.

Screenshot showing how to reorder work items.

Don't use the bulk modify function to change the value of the backlog priority field. While you can assign a value to these fields, you assign the same value to all items you've selected for bulk edit.

The preferred method for bulk edit is to use multi-select to move items to the top, bottom, or specific position within the page. If you must edit one of the backlog order fields in bulk to get a large number of work items in the priority order you want, use Excel. You can export a query containing the backlog items, update either the Backlog Priority or Stack Rank fields, and then publish your changes.

In Progress items and work listed on the backlog

Backlogs are designed to display work that corresponds to a Proposed, In Progress, or Resolved category state. Once you've completed work and its state enters a Done, or Closed state, then it falls off the backlog view. You can always create a query to view completed work, or view the Recently completed pivot from the Work Items page.

In general, you display all items that are in the In Progress category state, which corresponds to the Active and Committed states. To focus on work that is proposed but not in progress, you can toggle the backlog view to turn off In Progress. This toggle is useful when forecasting your product backlog.

If your backlog is missing items, check whether the In Progress view is turned off. For more information, see Workflow states and state categories.

Organize your backlog by mapping and reparenting backlog items

When you have many initiatives your teams are working on, you may want to group the work according to these initiatives. By defining features and epics, you can group your work into a three-tiered hierarchy consisting of epics, features, and backlog items.

For example, here the Customer Service team has organized several backlog items under two features and one epic.

Screenshot of Backlog that shows parents and multi-team ownership.

Screenshot of Backlog that shows parents and multi-team ownership, Azure DevOps Server 2019 and earlier versions.


When you assign your backlog items to sprints, you'll gain access to an in-context velocity report for both product and portfolio backlogs. Velocity helps teams determine how much work they can perform sprint-over-sprint.

You can quickly configure the Velocity report to count work items or sum Story Points, Effort, Remaining Work or other numeric field.

Open Velocity Analytics

When you assign your product backlog items to sprints, you'll gain access to an in-context velocity report for your product backlog. Velocity helps teams determine how much work they can perform sprint-over-sprint.

The report tracks the team's estimated backlog work—sum of Effort (Basic or Scrum processes), Story Points (Agile process), or Size (CMMI process—that your team has completed (green) in the previous sprints, or that are still in progress (blue).

Web portal, Velocity chart showing seven sprints of in progress and completed work

For more information, see View or configure team velocity

Display rollup progress counts, or totals

Product and portfolio backlogs support rollup columns. You can add one or more rollup columns to display progress bars, counts of descendant work items, or totals of select numeric fields. Your settings persist for each page that you customize and are only valid for your views.

  • Progress bars indicate the percentage of descendant items within a hierarchy that are closed or completed.
  • Counts display the total number of descendant items.
  • Totals provide a sum of numeric fields, such as Effort, Story Points, Completed Work, or Remaining Work of descendant items.

The following example shows progress bars for a portfolio backlog.

Screenshot example of epic, feature, and user stories progress.

Work with multi-team ownership of backlog items

When you have several teams, your hierarchical views may show items that belong to other teams.

View backlog items and parent items owned by other teams

Your team's product backlog lists only those items whose area path matches items assigned to your team. But, if you show parents, you see the parent epic of the features and backlog items, even if another team owns the epic or feature.

Other team-owned items appear with an information icon .

Screenshot of backlog items and parent items owned by other teams.


Add the Node Name field as a column to identify the area path/team associated with the work items.

Other team-owned items appear with an information icon .

Screenshot of backlog items and parent items owned by other teams, Azure DevOps Server 2019 version.


Add the Node Name field as a column to identify the area path/team associated with the work items.

For more information, see Define area paths and assign to a team.

View epics and child items owned by other teams

Here's another example that shows the Epics backlog for the Management team. Drilling down, you can see all the backlog items and features, even though they belong to one of three different teams: Customer Service, Phone, and Web.

Screenshot of view Epics and child items owned by other teams.

Screenshot of view iew Epics and child items owned by other teams, Azure DevOps Server 2019 version.

From these views, you can reparent items that you own and items other teams own. But, you can't reorder items that another team owns.

This organization enables management teams to focus on high-level features and epics, and development teams to focus on just the backlog items they're responsible to deliver. Add teams and set their area paths. For example, you can create a team structure similar to this one with two management and three development teams.

Conceptual image of backlogs and multi-team ownership.

For more information about hierarchical team and backlog structures, see Portfolio management.


You have the flexibility to establish child links with work items from different projects. However, if the processes differ between projects, the hierarchy won't be visible on the backlog for those child items residing in the separate projects. Nonetheless, you can view all of the associated child items directly on the work item form.

Reordering and reparenting work items

All backlogs and boards support dragging to reorder and reparent work items. Updates made to one team's backlogs and boards are reflected in other team backlogs and boards that share the same area path. You may need to refresh the page to view the changes.

You can only use dragging to reorder or reparent work items assigned to area paths selected for your team. When the Parents view option is enabled, work items may appear on your backlog that your team doesn't own. Anything that appears with the information icon can't be reordered nor reparented as another team owns it.

Screenshot of information message on team ownership.

Display leaf node work items

For TFS 2018 and earlier versions, the Kanban board only shows the leaf node with nested items of a same-category hierarchy. For all versions, sprint backlogs and Taskboards only show the last node in a same-category hierarchy, called the leaf node.

While you can create a hierarchy of backlog items, tasks, and bugs—we don't recommend that you create same-category hierarchies. In other words, don't create parent-child links among work items of the same type, such as story-story, bug-bug, or task-task. The last node in a same-category hierarchy may only appear on Kanban boards, sprint backlogs, and Taskboards. For example, if you link items within a same-category hierarchy that is four levels deep, only the items at the fourth level appear on the Kanban board, sprint backlog, and taskboard.

Rather than nest requirements, bugs, and tasks, we recommend that you maintain a flat list. Only create parent-child links one level deep between items that belong to a different category. For more information, see Fix re-ordering and nesting issues, How backlogs and boards display hierarchical (nested) items.

Product backlog controls

You can use the following controls to change or filter your product backlog view.


If you turn the In Progress control off, then items that are in the Active, Committed, or Resolved states or in the In Progress category workflow state won't appear in the backlog. To learn more about category workflow states, see How to use workflow states and state categories.

For more information about using each of these controls, see Configure your backlog view.

Icon or Link




Backlog selector

View options

View options




full screen / exit full screen

Full screen

Enter or exit full screen mode

expand icon / collapse icon


Expand or collapse one level of the tree hierarchy


Even if you have show parents turned on, the Create Query and Email mail icon controls only list items at the currently selected level.

Permissions and access

As a member added to the Contributors group of a project, you can use most features provided under Boards or Work. Users with Basic access have full access to all features. Users with Stakeholder access are limited to certain features. For more information, see Stakeholder access quick reference.

For more information about permissions and access, see Permissions and access for work tracking and Stakeholder access quick reference.

To add users to a project, see Add users to a project or team.

Add portfolio backlogs and boards

To add a portfolio backlog or board, customize your process, add new work item types, and then configuring your backlogs and boards. You can also add or modify the fields defined for a work item type (WIT) or add a custom WIT. For more information, see Customize an inheritance process and Customize your backlogs or boards (Inheritance process).

To add a portfolio backlog or board, either customize your inherited process or modify your XML definition files. You can also add or modify the fields defined for a work item type (WIT) or add a custom WIT. For more information, see the following articles based on the process model used to update your project:

Inheritance process model:

On-premises XML process model:

Next steps

If you're just getting started, see Start using Azure Boards.