Azure DevOps Roadmap: Build a Cross-Team Plan With Delivery Plans
10 min read ยท 2026-10-25
An Azure DevOps roadmap is a timeline of your epics and features, built in Azure Boards, that shows what each team plans to deliver and when. Most teams build it with Delivery Plans, which put several team backlogs side by side on one calendar. The view is only as good as the data under it: one area path per team, dated iterations, and features that roll up to epics.
The plan below takes six weeks: setup, backlog cleanup, the Delivery Plan, dependencies and a monthly review. After it you will find a filled-in example for three teams, who owns what, the metrics to watch and how to turn the plan into one slide for leadership.
The roadmap at a glance
Goal: A Delivery Plan in Azure Boards that shows every team's dated features under shared epics, with dependencies linked and a monthly review with leadership in place. Duration: 6 weeks
Agree what the roadmap must answer (Week 1)
Decide who reads the roadmap, which questions it answers and how far ahead it looks.
- List the readers: the CTO, the head of product, the sales or customer success lead, and the team leads who plan against it.
- Write down the three questions it must answer, such as what ships this quarter, what is at risk, and what depends on another team.
- Pick the horizon. A common starting point is the current quarter in feature detail and the next two quarters at epic level.
- Name one roadmap owner, usually the product owner or program manager, who keeps the plan current.
Milestone: A one-page roadmap charter with readers, questions, horizon and owner, approved by the head of product or engineering.
Set up teams, areas and iterations (Week 2)
Give every team its own area path and a shared sprint calendar so dates line up on one timeline.
- In Project settings, open Project configuration under Boards and create iterations with start and end dates for the next two quarters.
- Create one area path per team, then select each team's areas and iterations in Team configuration.
- Use the same sprint length and start day for all teams that will appear on the same plan.
- In Team configuration, check that each team shows the backlog levels it plans with, such as Epics and Features.
Milestone: Every team has a default area path and dated iterations for the next two quarters, checked by the Azure DevOps project administrator.
Clean the backlog hierarchy (Weeks 2-3)
Make every feature roll up to an epic and carry an owner and a date range.
- Create epics for business outcomes, such as Self-service billing, not for team names or technical layers.
- Break each epic into features that one team can finish in one to three sprints.
- Open the Features backlog, turn on the Mapping pane and drag each feature onto its parent epic.
- Fill in Start Date and Target Date on features and epics, or assign each feature to an iteration.
Milestone: Every open feature has a parent epic, an owner and a date range or iteration. A query for open features without a parent returns zero rows.
Build the Delivery Plan (Week 4)
Put all team backlogs on one timeline that leaders can scan in a minute.
- Go to Boards, then Delivery Plans, and select New plan.
- Add each team with its Features backlog, then add one more row with the Epics backlog for the portfolio view.
- In the plan settings, use Field criteria to hide work you do not want on the roadmap, such as items tagged internal.
- Add Markers for fixed dates such as a release, a code freeze or a customer event.
- Under Fields, choose what each card shows, such as Assigned To, State and Tags.
Milestone: A Delivery Plan that shows every team's features for the next quarter, shared with the readers named in the charter.
Link dependencies and flag risks (Week 5)
Make cross-team dependencies visible before they turn into late surprises.
- For each feature that needs another team's work, add a Predecessor or Successor link to that team's feature.
- Open the plan, show the dependency lines and fix any link where the successor is planned before its predecessor.
- Add an at-risk tag to features in trouble and give it a red color under Tag colors in the plan settings.
- Record each risk with an owner and a fallback on a page of the project wiki.
Milestone: All cross-team dependencies for the quarter are linked, and every at-risk feature has an owner and a fallback in the risk log.
Run the review rhythm (Week 6)
Keep the roadmap current and turn it into a monthly leadership update.
- Ask each team lead to update dates and states on their features before every sprint planning.
- Hold a 30-minute monthly roadmap review with product, engineering and the business owner.
- Save a query of open features and epics, then export it to CSV for readers who do not use Azure DevOps.
Milestone: First monthly roadmap review held, with decisions and date changes written on the roadmap wiki page.
Your Azure DevOps roadmap vs Microsoft's Azure DevOps roadmap
The same search brings up two different things. One is the roadmap you build inside Azure DevOps for your own product or program. That is what this guide covers. The other is the Azure DevOps Roadmap page that Microsoft publishes on Microsoft Learn. It lists features Microsoft plans to ship in Azure DevOps Services and Azure DevOps Server, each with an expected timeframe, and Microsoft states that these plans can change.
Microsoft's page is still useful to you. If your plan depends on a feature Microsoft has announced, check its timeframe there before you commit a date. Treat it as an outside dependency in your risk log, with a fallback such as a workaround your team can build.
Which Azure DevOps features to use
You do not need extensions to build a solid roadmap. Delivery Plans is part of Azure Boards, and the rest comes from features most teams already use.
Your work item names depend on the process your project uses. In the Agile process the levels are Epic, Feature, User Story and Task. Scrum uses Product Backlog Item instead of User Story, CMMI uses Requirement, and the Basic process uses Epic, Issue and Task. Keep the roadmap at Epic and Feature level whatever the process. Stories and tasks belong in sprint planning.
- Delivery Plans: the timeline itself, with one row per team backlog, markers for key dates and dependency lines.
- Backlogs with the Mapping pane: the fastest way to attach features to epics and spot orphans.
- Queries: a Tree of work items query gives you epics with their features for reviews and exports.
- Dashboards: Analytics widgets such as Velocity, Cumulative Flow Diagram and Cycle Time show whether the dates are realistic.
Example: a one-quarter roadmap for three teams
Picture a B2B software company launching self-service billing. Three teams work on it: Web, Payments and Mobile, each with two-week sprints that start on the same Monday. The epic is Self-service billing, with a target date at the end of the quarter and a marker for the public launch.
Here is how the Delivery Plan reads, month by month. Each line names the feature, the owner and the milestone a leader can check.
- Month 1, Payments team: feature Payment provider integration, owner Payments engineering manager. Milestone: test payments succeed in staging. It is the predecessor for two Web features.
- Month 1, Web team: feature Billing settings page, owner Web product owner. Milestone: page live behind a feature flag for internal users.
- Month 2, Web team: feature Plan upgrade and downgrade flow, owner Web product owner. Milestone: pilot customers can change plans without contacting support. Successor of the payment integration.
- Month 2, Mobile team: feature Invoice history in the app, owner Mobile team lead. Milestone: build approved in internal testing. Tagged at-risk because the invoice API is not final.
- Month 3, all teams: feature Launch readiness, owner program manager. Milestone: support runbook signed off, code freeze marker passed, launch marker met.
Who owns what
A roadmap goes stale fast when everyone assumes someone else updates it. Write the owners on the wiki page next to the charter.
The rule that matters most: the person who owns a feature also owns its dates. The program manager can chase updates, but should not change another team's dates without that team's agreement.
- Head of product or engineering (sponsor): approves the charter and the horizon, and makes the trade-off calls when dates slip.
- Product owners: own epics and features, their order and their Start Date and Target Date.
- Engineering managers or team leads: confirm capacity and update feature states every sprint.
- Program manager or release train engineer: owns the Delivery Plan, the dependency links, the risk log and the monthly review.
- Azure DevOps project administrator: manages area paths, iterations, team settings and plan permissions.
- Business stakeholders (sales, customer success, marketing): read the plan, raise customer commitments early and never promise dates the plan does not show.
How to present it to leadership
Leaders do not want to read cards. Build one slide in PowerPoint or Google Slides. At the top, write the outcome for the quarter in one sentence. Below it, paste a screenshot of the Delivery Plan with only the Epics row expanded, or redraw the epics as horizontal bars by month. Color each epic green, amber or red, and add the two or three markers that matter, such as launch and code freeze.
Under the timeline, list what changed since last month, the top three risks with owners, and the one decision you need. Leave out story points, sprint numbers and anything about how Azure DevOps is configured. If a leader asks for detail, open the live plan and drill into one epic.
Metrics to track
A roadmap earns trust when its dates hold. Track a few numbers each month and show the trend, not a single snapshot. All of them come from queries or Analytics widgets you already have.
Keep targets modest at first. The goal of the first quarter is a roadmap people believe.
- Features delivered as planned: features closed in the iteration or by the Target Date set at the start of the quarter, out of all planned features.
- Roadmap freshness: open features whose Target Date is already in the past. This number should be zero before every review.
- Dependency health: dependency links flagged as a problem on the plan, counted before each review.
- Feature cycle time: time from Active to Closed for features, from the Cycle Time widget on a team dashboard.
How to adapt it
A single team does not need a Delivery Plan at first. Use the Features backlog with dates, a Tree of work items query and a monthly screenshot for stakeholders. Add a plan when a second team starts sharing work with you.
A large program should keep one Delivery Plan per program and one portfolio plan at epic level for leadership. If you run Azure DevOps Server, check which Delivery Plans settings your version includes before you promise a layout. In a regulated setting, keep approvals and the changelog on the wiki so you can show who agreed to each date change.
Common mistakes to avoid
- Teams that run sprints on different calendars make the plan impossible to compare, so agree on one sprint length and start day for every team on the plan.
- Epics are named after teams or components, which tells leaders nothing, so name each epic after the business outcome it delivers.
- Features float without a parent epic and vanish from the portfolio view, so run the orphan query before every review and fix what it finds.
- Dependencies kept in meeting notes surprise everyone in month two, so add Predecessor and Successor links the day a dependency is agreed.
- The roadmap shows every story and task, and leaders stop reading it, so keep it at Epic and Feature level and leave the rest to sprint planning.
- Updating dates only before big meetings leaves the plan wrong most of the time, so make date updates part of every sprint planning.
Frequently asked questions
Does Azure DevOps have a roadmap feature?
Yes. Delivery Plans in Azure Boards is the built-in roadmap view. It shows the backlogs of several teams on one timeline, with markers for key dates and lines for dependencies between work items.
How do I create a roadmap in Azure DevOps?
Set dated iterations and one area path per team, link features to epics, and give features dates or iterations. Then go to Boards, open Delivery Plans, select New plan and add each team's Features backlog. Add markers for key dates and link dependencies.
Can I show dependencies on an Azure DevOps roadmap?
Yes. Link work items with Predecessor and Successor links and the Delivery Plan shows the dependency between them. Review the lines before each roadmap meeting and fix any successor that is planned before its predecessor.
How do I share an Azure DevOps roadmap with people who do not use Azure DevOps?
Export a query of epics and features to CSV and open it in Excel, or put a screenshot of the Delivery Plan on a single slide. Check in your organization settings which access level your viewers need if you want them to open the live plan.
Where can I see Microsoft's roadmap for Azure DevOps?
Microsoft publishes an Azure DevOps Roadmap page on Microsoft Learn. It lists planned features for Azure DevOps Services and Azure DevOps Server with an expected timeframe. Microsoft notes that these plans can change, so treat any date there as a dependency with a fallback.