Cross-team Features in Azure DevOps

Question

Hi Team,

I'm looking for guidance on the best way to manage and view cross-team Features in Azure DevOps. If there is a better approach than the options below, please feel free to suggest an alternative.

Context

We currently plan Features for the upcoming quarter using Excel, as we have more than 15 teams involved. A common scenario is where Team A requires work from a Central Team. We need a way for the Central Team to clearly see all incoming Feature requests from multiple teams, while also allowing requesting teams to maintain visibility of their own work.

Option 1: Assign the Feature to the Central Team

Team A creates a Feature and sets the Area Path and Iteration Path to the Central Team.
The Feature then appears on the Central Team's backlog.

Challenges:

The Feature disappears from Team A's backlog when filtering by Feature level.
The Central Team can see the Feature but has no obvious indication of which team requested it, unless they check the work item history.
Since the Area Path is changed to the Central Team, ownership and reporting become less clear.

Option 2: Use Dependencies

Team A creates the Feature in their own Area Path and Iteration Path.
Team A creates a dependency relationship with the Central Team's work item (Predecessor/Successor).

Challenges:

This requires additional work items because dependencies cannot be used as a Parent/Child relationship.
Not all requests are true dependencies; often Team A is simply asking the Central Team to deliver a piece of work.
Managing multiple linked Features across 15+ teams could become difficult.

Question

How does Azure DevOps best support cross-team Feature requests where:

A requesting team needs visibility of the Feature on their backlog.
The Central Team needs a consolidated view of all Feature requests coming from multiple teams.
The originating/requesting team is clearly visible.
Prioritisation and reporting can be managed centrally.

Accepted Answer

Hello @SB ,

Welcome to Microsoft Q&A portal. Thank you for asking your question here.

In Azure DevOps, work item visibility on team backlogs is strictly controlled by Area Paths. When you change a Feature's Area Path to the Central Team (Option 1), it moves ownership entirely, causing the Feature to disappear from Team A's default backlog.

To meet your requirements giving the Central Team a consolidated intake view while allowing requesting teams to track their requests, we recommend leveraging Azure DevOps' native Portfolio Backlog hierarchy and Delivery Plans, supplemented by an inherited process customization.

Recommended Solution: The Hierarchical Portfolio & Delivery Plan Model

1. Decouple Demand from Delivery via Hierarchy (Parent/Child)

Instead of transferring the same Feature back and forth between Area Paths, separate the request from the execution:

Requesting Team (e.g., Team A) owns the Parent Item: Team A creates an Epic (or Feature) in ProjectName\Team A. This ensures the request remains permanently visible on Team A's backlog and Kanban board.
Central Team owns the Delivery Child Items: The Central Team creates the delivery Feature (or User Stories/Tasks) under ProjectName\Central Team, linking it as a Child to Team A's parent item.

As highlighted in the official documentation for Managing product and portfolio backlogs:

"You can view backlog items and see their parent items, even if the parent items are owned by another team. When you turn on Show parents, the backlog displays the parent-child hierarchy across area paths."

By enabling Show parents and adding the Node Name (Area Path) column on the Central Team’s backlog, the Central Team instantly sees all incoming work and exactly which team requested it.

2. Implement an "Originating Team" Custom Field

If your operational model strictly requires managing a single Feature work item without splitting into parent/child items:

Customize your inherited process to add a custom picklist field called Requesting Team on the Feature work item type.
Assign the Feature's Area Path to the Central Team (ProjectName\Central Team) so it appears on their backlog for centralized prioritization and delivery.
Because moving the Area Path removes the item from Team A's backlog, Team A can maintain visibility by creating a shared Query (Work Item Type = Feature AND Requesting Team = Team A) and pinning a Query Results widget directly onto Team A's project dashboard.

3. Coordinate Timelines with Delivery Plans

For multi-team alignment without spreadsheets, use Delivery Plans. You can include backlogs from all 15+ requesting teams alongside the Central Team on a single, interactive calendar schedule.

From the official documentation on Reviewing team delivery plans in Azure Boards:

"Delivery Plans provide a highly interactive calendar schedule of multiple team backlogs. With Delivery Plans, you can gain visibility into your organization's alignment to its goals by viewing multiple team backlogs and their work items on a timeline."

Using Plan Settings → Styles, you can color-code cards based on the Requesting Team custom field or Area Path, giving stakeholders an instant visual heat map of cross-team commitments.

Please let me know your thoughts in comments.

Answer

The best fit is usually a portfolio backlog model with single ownership by Area Path, not moving the same Feature back and forth between teams.

A practical pattern is:

Keep ownership with one team per work item via Area Path. Azure DevOps uses Area Path to determine which team backlog and board show the item. If a Feature is reassigned to the Central Team’s Area Path, it will appear on the Central Team backlog and no longer appear on Team A’s backlog as that team’s own item.
Let requesting teams keep their own higher-level item. A management/requesting team can keep the Epic or parent item in its own Area Path, while the Central Team owns the Feature or child backlog items needed to deliver the work. Azure DevOps supports hierarchical views where teams can see parent or child items owned by other teams.
Use portfolio backlogs for cross-team visibility. Management teams can use portfolio backlogs to:
- review and reorder Features
- drill down into child Stories/PBIs owned by other teams
- see parent and child items across teams
Turn on parent visibility and add the Node Name column. When Parents or Show parents is enabled, a team can see parent Epics or Features owned by another team. Adding Node Name helps identify which Area Path/team owns each work item.
Use Delivery Plans when timeline coordination is needed. Delivery Plans provide a calendar/timeline view across multiple teams’ backlogs and are better when the main need is coordinated scheduling across many teams.
Use dashboards/Analytics widgets for consolidated reporting. Dashboards can include Analytics-based widgets for multiple teams in one project to monitor status and progress across teams.

For the specific requirements:

Requesting team needs visibility on its backlog: keep the requesting team’s parent Epic in that team’s Area Path, and let the Central Team own the delivery Feature or child items. The requesting team can enable parent visibility to keep context.
Central Team needs a consolidated view: use the Central Team backlog for items in its Area Path, and use portfolio backlogs, queries, dashboards, or Delivery Plans for broader cross-team visibility.
Originating/requesting team must be clearly visible: the supported documentation shows ownership by Area Path via Node Name, but it does not provide a built-in “originating team” field when ownership changes. A Microsoft Q&A resolution recommends adding a custom field such as Requesting Team or Originating Team on the Feature so the Central Team can distinguish self-created work from incoming requests and report on it.
Central prioritization/reporting: use a management team with portfolio backlogs to review priorities and reorder Features, plus dashboards for reporting.

Based on the documented behavior, Option 1 by itself is not ideal because changing Area Path changes ownership and removes the item from the original team’s backlog. Option 2 can work for dependency tracking, but it adds extra linked items and is not the best primary model for simple cross-team demand.

The strongest approach is:

Management/requesting team owns the Epic
Central Team owns the delivery Feature or child work items via its Area Path
Use portfolio backlogs and Delivery Plans for cross-team visibility
Add a custom field like Requesting Team for clear origin tracking and reporting

This keeps ownership clear, preserves backlog behavior, and gives the Central Team a consolidated intake/reporting model without relying on work item history.

References: