Manage priorities and gain visibility across teams

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

Agile tools provide each team a wealth of ways to gain visibility into their work—to manage priorities and status and to monitor progress and trends. However, how do you gain visibility across several teams? What tools should you use?

You have three main ways to track progress across several teams.

  • Management teams can define Delivery Plans that provide visibility into the deliverables several teams have scheduled
  • Each management team can use their Agile tools, and in particular portfolio backlogs, to gain visibility of the feature teams defined under their area path
  • Management teams can create dashboards that monitor status, progress, and trends across several teams.

For an overview of all team tools, see Manage teams and configure team tools.

Delivery Plans support a view of team backlogs on a calendar timeline

With a Delivery Plan, you gain a tailor-made view across several teams and their development backlogs—stories, features, or epics. You can use these views to drive alignment across teams by overlaying several backlogs onto your delivery schedule.

When you configure a Delivery Plan, you select the teams and backlog levels of interest. You can then interact with the plan to update it and drill into more details. To learn more about Delivery Plans, see Review team plans.

Screenshot with callouts of Delivery Plans, collapsed teams.

When you configure a Delivery Plan, you select the teams and backlog levels of interest. You can then interact with the plan to update it and drill into more details. To learn more about Delivery Plans, see Delivery Plans.

Interactive plan elements

Use portfolio backlogs to track features and epics

The first level of gaining visibility across several teams is to configure your teams and backlogs to support the views you want.

We recommend that you structure your teams as follows:

  • Add a management team for a group of feature teams; these teams own epics and turn on only the Epic portfolio backlog level
  • Add feature teams to manage features, stories and tasks, and turn on the stories and features backlog levels

The management team creates the epics. Then, they or their feature teams break down the epics into features and then map their features to the epics on the management backlog.


By breaking down large goals, epics, scenarios, or features into smaller ones, teams can make better estimates and identify risks and dependencies.

Limiting the backlog levels for each team—Epics for management teams and Features and Stories for feature teams—helps each team to stay focused on monitoring the progress of their work. For details on managing team backlog levels, see Select backlog navigation levels.

With the multi-team portfolio backlog view, you can:

  • Review priorities with your team and reorder features to support current priorities
  • You can drill down to see the status of each feature's child user stories or PBIs
  • Filter the backlog based on keyword or tag to focus on specific teams or categorized items
  • (Optional) You can use the mapping feature to map user stories or PBIs to features

View child items owned by other teams

Management teams can drill down from their portfolio backlog to see how Epics are progressing. 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.

Items that are owned by other teams appear with an information icon, .

Backlog that shows parents and multi-team ownership


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

View backlog items and parent items owned by other teams

Feature teams can turn Show parents on their backlogs to see context and those items owned by other teams.

Items that are owned by other teams appear with an information icon, .

Items that are owned by other teams appear with an information icon.


When estimating stories or product backlog items, start with one story point per person per day. Feature teams can later calibrate and adjust those estimates as needed. For example, the velocity of a seasoned team is higher than a new team. The size of the work stays the same, but a seasoned team can just deliver faster.

To learn more about this configuration, see Portfolio management, Add teams, and Organize your backlog.

Add management dashboards with multi-team views

A second method for gaining visibility across teams is to define multi-team focused dashboards that let you view progress, status, and trends. You do define focused dashboards primarily by defining queries that either capture the progress of a single team or several teams. You can then create charts and view trends for each team or for several teams.

The two areas of most interest to management teams are project health and bug debt. The widget catalog provides 10+ widgets you can add to a dashboard to track the status, progress, and health of your project and teams. Also, you can find other widgets in the Visual Studio Marketplace, Azure DevOps tab.

For example, here we've added three query-based charts, one for each team, to a dashboard that shows the active and resolved bugs over the previous four weeks.

Bug debt, Email team Bug debt, Voice team Bug debt, Web team

When you define multi-team dashboards, consider the following questions:

  • What are you wanting to learn and how will it drive your organization's actions?
  • What time frame is of interest?

Review Agile culture and Practices that scale for guidance on team autonomy and organizational alignment.

Project health and progress against goals dashboard

Use the Query Results widget to provide a list of features by state:

  • Completed features (Done or Closed)
  • New features (New or Proposed)
  • Features being actively worked (In Progress or Active)

Use the Chart for work items widget to add query-based charts. To learn more about creating query-based charts, see Charts.

Technical debt, bug debt, and activity dashboard

Another measure of project health and the health of the teams is to monitor bug activity and bug debt. Consider the charts you can create that will help you answer these questions:

  • Are bugs getting fixed? At a rate that's acceptable?
  • How stale are bugs?
  • Is the bug debt per team being maintained?
  • Is the ratio of high priority bugs being kept within organizational goals?

For tips on creating queries based on counts or numeric fields, see Query by numeric field.

Use the Analytics Service to gain visibility across teams

You can add Widgets based on the Analytics Service to a dashboard that show progress for a team. From one dashboard, you can add widgets for any team within the project.

Track capacity when working on more than one team

You can track capacity for individuals that participate on more than one team. To learn how, see Set sprint capacity, Track capacity when working on more than one team.

Limitations of multi-team board views

While the management teams you configure can use the board to monitor feature progress by turning on the Features backlog, there are limitations inherent within these views. Even if the management team and the feature teams configure their Feature board columns with identical workflow mapping, updating the Features on one team's board won't be reflected on another team's board. Only when the work item state changes does the card column reflect the same on all boards.


Work items that appear on more than one team's board can yield query results that don't meet your expectations. Because each team can customize the board columns and swimlanes, the values assigned to work items which appear on different boards may not be the same. The primary work around for this issue is to maintain single ownership of work items by team area path. Another option is to add custom workflow states which all teams can use. For more information, see Customize your work tracking experience.

As you can see, there are many ways you can monitor progress and trends across several teams. The methods you choose depend on your focus and organizational goals.

Here are some other articles that address working with multiple teams: