Let’s walk through the exact process I use to architect, optimize, and maintain high-performing Azure Delivery Plans.
Azure DevOps Delivery Plans
What Are Azure DevOps Delivery Plans?
Let’s define exactly what a Delivery Plan is—and more importantly, what it isn’t. A Delivery Plan is a dynamic, native timeline canvas in Azure Boards that overlays the work items of multiple teams onto a single calendar view governed by your organization’s iteration paths (sprints).
Think of it as a virtual planning wall that cuts horizontally across your organizational silos.
Key Capabilities at a Glance
- Multi-Team Aggregation: View work from up to 15 different teams and multiple backlogs on a single screen.
- Live Sprints Synchronization: Unlike a static PowerPoint deck or third-party Gantt chart, if a developer shifts a card’s target sprint on a team board, the Delivery Plan instantly updates.
- Native Dependency Mapping: Visually trace links between upstream and downstream work items across your entire enterprise directory.
Choosing Your Visibility Level: Epics vs. Features
| Roadmap View Type | Target Audience | Primary Backlog Level | Optimal Planning Window |
| Executive Portfolio Plan | VPs, Directors, Chief Product Officers | Epics | 2 to 4 Quarters |
| Cross-Team Program Plan | Product Managers, Scrum Masters, Release Trains | Features | 3 to 6 Sprints |
| Tactical Coordination Plan | Team Leads, Senior Engineers | User Stories / Requirements | 1 to 2 Sprints |
The “One Level” Rule
When configuring a plan, select one primary backlog level per plan. If you are building a roadmap for a program steering committee, track the Features backlog.
Mixing User Stories and Epics on the same canvas increases visual density and dilutes the roadmap’s core message.
Configuring Sprints and Standardization
A Delivery Plan is only as accurate as the underlying configuration of your project settings. If your teams operate in localized silos with completely asymmetric sprint schedules, your global timeline will look disjointed.
Standardizing the Iteration Cadence
Before onboarded teams can share a unified canvas, you must establish standard Iteration Paths at the project level.
- Ensure that team sprint start and end dates match exactly across your portfolio.
- Adopt a clean, predictable naming standard (e.g.,
ProjectName\2026\Sprint 01) rather than letting each team name their sprints arbitrarily.
Setting Up the Delivery Plan Canvas
When you create a new plan, you will define the scope by targeting the exact teams and backlog levels relevant to your initiative:
- Navigate to Boards > Delivery Plans and click New Plan.
- Input a descriptive name (e.g.,
FY26 H1 Cloud Migration Roadmap). - Add your target teams one by one. For each team, specify whether you want to track their Epics, Features, or Stories.
- Apply criteria filters if necessary to isolate specific work (for example, filtering out operational maintenance work to focus strictly on net-new product development). Check out the screenshot below for your reference.
Advanced Dependency Tracking and Resolution
Visualizing the Link Network
Azure DevOps tracks dependencies through work item links, specifically utilizing the Predecessor / Successor relationship model. When these links are accurately established between work items owned by different squads, the Delivery Plan automatically surfaces them with distinct visual indicators.
- Green Dependency Lines: Indicate that the upstream work item (Predecessor) is scheduled to finish in a sprint before the downstream work item (Successor) begins. The workflow is healthy.
- Red Dependency Lines: Indicate a critical scheduling