When teams ask us for a Jira roadmap for multiple projects, they usually describe it as a project management tool problem. "Jira can't show all our projects on one timeline." "Leadership wants something cleaner." Fair enough. But when we dig in on calls, the real problem is almost always one level up. The roadmap breaks at the epic.
Here's what that sounds like in practice:
- Epics don't match the themes the company actually works on, so leadership can't read the roadmap even when every project is on one screen.
- Teams add a custom level above epics, then still duplicate each project as an epic so it shows up on the timeline.
- Client or program work needs four or five levels, while Jira's default hierarchy offers three.
- New requests land in Jira as epics long before anyone decides whether they're real projects, so the roadmap fills up with ideas.
In every case, the tool wasn't the first thing to fix. The hierarchy was. This post is about getting that right before you build the roadmap, and about where Advanced Roadmaps (now called Plans) helps. Get the levels right, and the roadmap becomes a source of truth instead of one more document to update.
Full disclosure: I'm on the Planyway team, and I'll mention where our app fits. Most of this is about Jira itself.
TL;DR
- A multi-project roadmap needs a level that leadership actually talks about: initiatives, themes, programs. Epics are usually too small and too many.
- Jira's default hierarchy stops at the epic. On Premium and Enterprise, you can add custom levels above it and use them in Jira Plans (formerly Advanced Roadmaps).
- Design the hierarchy before you build the roadmap. Changes apply site-wide and can't be undone.
- No Premium? You can get most of the way there with fields and grouping, but the workaround has limits.
- Once the levels are right, dependencies, capacity, and milestones finally make sense at the roadmap level.
Why multi-project roadmaps get noisy at the epic level
Epics are built for teams. A team breaks a feature into an epic, the epic into stories, and plans its sprints around them. That works within individual projects, where everyone is on the same page.
Put ten projects on one roadmap, and you get two hundred epics.
Some are three-day chunks of work, some are six-month programs, and some are leftovers nobody closed.
Executives looking at that screen don't get a comprehensive overview, and they can't tell what matters, so project managers start rebuilding a cleaner version somewhere else: a slide, a spreadsheet, a PDF.
The cleaner version almost always has one thing in common. It groups work into a level above epics, the level leadership actually talks about:
- Initiatives or themes: "Self-service onboarding", "EU expansion", "Platform reliability".
- Client projects: for agencies and consultancies, the client engagement is the thing everyone tracks.
- Programs: a set of related projects that share the same goal and a deadline.
If that level doesn't exist in Jira, it gets maintained by hand outside Jira. That's where the extra hours and the out-of-date roadmaps come from, and why the roadmap stops being useful for strategic planning.
Jira's default hierarchy and what Timeline can show
Out of the box, Jira Software has three levels:
Level | Default work type | What it's for |
|---|
1 | Epic | A larger piece of work, usually weeks to months |
0 | Story, Task, Bug | Standard work a team picks up in a sprint |
-1 | Subtask | Smaller steps inside a story or task |
On every plan, you can rename these levels and change which work types sit on each one. What you can't do on Free or Standard is add anything above the epic.
The built-in Timeline view follows the same limits. It's a simple visual representation of a single Jira project: epics as bars, their child work items underneath, basic dependencies. But it lives inside one space, so it can't show different projects side by side, and it has nothing above the epic to group them by. For a roadmap across multiple teams, that's two walls at once.
Adding levels above epics with Advanced Roadmaps (Jira Plans)
On Jira Premium and Enterprise, two things change.
First, you can add custom hierarchy levels above the epic, for example, Initiative, and above that, Theme or Program. An admin does this in Settings → Work items → Work type hierarchy.
Second, you get Plans, which used to be called Advanced Roadmaps (you'll still see it called Jira Advanced Roadmaps all over the Community). Plans is where those extra levels become a roadmap, and it's one of Atlassian's more robust tools for strategic alignment across teams.
Key takeaways: Advanced Roadmaps (Jira Plans)
- Pulls work from multiple projects, multiple Jira boards, and saved filters into one plan.
- Shows the full hierarchy, so you can roll epics up into initiatives and see the project's progress at the level leadership cares about.
- Lets you choose which levels a plan shows, from an initiative-only overview down to individual tasks.
- Groups work by team and tracks team capacity per sprint, based on team velocity in story points or hours, which helps with resource allocation.
- Helps with managing dependencies across teams and lining up cross project releases.
- Keeps changes in the plan until you review and save them to Jira, which makes scenario planning safer.
- Supports multiple plans, for example one per program or department.
Before you add a level: read the fine print
Atlassian is clear that hierarchy changes are serious:
- They apply to all company-managed spaces on the site, not just one project.
- Changing the hierarchy can break existing parent-child links between work items.
- The changes can't be undone.
- It's set up for company-managed spaces; team-managed spaces handle hierarchy differently.
So don't add levels on a Friday afternoon. Design them first.
How to design the hierarchy before building the roadmap
These are the questions we'd answer on paper before touching any settings. Each one pays off later in better decision making.
1. What does leadership talk about in meetings?
Listen to the next planning or steering meeting. If people say "How's EU expansion going?", that's a level. If they say "How's the Acme project?", that's a level. The words they use are your level names, and they usually map straight to business goals. Don't invent new jargon for the roadmap.
2. How many levels do you actually need?
Usually one level above epics is enough, two at most. Every extra level is something someone has to keep up to date. The team that runs five levels has a good reason (their client work really is structured that way), but most teams end up with Initiative → Epic → Story and stop there.
3. Is it a level, a space, or a field?
This is where most hierarchy mistakes happen.
- A level is for things that have their own dates and progress, like an initiative that runs for a quarter.
- A space (project) is for a team or a long-running product, even when cross functional teams contribute to it. Don't duplicate spaces as a hierarchy level; one of the teams we spoke with ended up maintaining every project twice because of that.
- A field (a label, component or custom field) is for tags you filter by, like region, client type or priority. They don't need their own bar on the timeline.
4. Where does work enter, and when does it become "real"?
If new requests arrive as epics from an intake form, your roadmap fills up with ideas that were never approved. Decide where requests live before approval and at which level they appear on the roadmap after it. That keeps project plans separate from wish lists and project timelines honest.
5. Who owns each level?
Initiatives usually belong to a product or program lead, epics to team leads, stories to team members. Match each level to team capabilities, not just job titles. If nobody owns a level, its dates and status will rot, and the roadmap will stop reflecting reality.
6. Test it before you roll it out
Because changes apply site-wide and can't be undone, try the new hierarchy on a sandbox site first, or at least map your existing epics to the new levels in a spreadsheet and check nothing ends up orphaned.
No Premium? Workarounds and their limits
On Standard, you can't add levels above the epic, but you can get part of the way there:
- A custom field or label for the initiative. Tag every epic with its initiative, then group or filter by it. You get the grouping, but not the roll-up: there's no initiative bar with its own dates and progress toward project goals.
- A dedicated "initiative" space. Some teams create one space just for initiatives and link epics to them with issue links. It works for reference, but the links aren't a real parent-child relationship, so nothing rolls up automatically.
- Naming conventions. "EU expansion: payment methods". Easy to start, easy to break.
All three keep the data in Jira, which is better than a slide. But if leadership needs initiative-level progress across multiple projects, you'll feel the limits quickly, especially in progress tracking.
This is also where a planning app can help. Planyway for Jira puts epics from as many spaces as you need on one timeline and groups them by space or by epic, so the cross-project view works on any plan.
➡️ Try Planyway free
And if you're on Premium and add custom levels, Planyway's Gantt and Table views show those levels too, the same way Plans does.
Then build the roadmap
With the levels in place, the roadmap becomes a strategic tool rather than just a picture, because every view has an obvious home.
Audience | Level they read | What they need to see |
|---|
Leadership | Initiatives (or your top level) | Status, key milestones, delivery dates, potential risks |
Project managers | Initiatives and epics | Dependencies across teams, release dates, team capacity |
Team leads | Epics and stories | Task assignments, sprint planning, dependent tasks |
A few things to get right at the roadmap level:
- Dependencies at the right level. Good dependency management starts with linking work where the dependency really is, usually between stories or epics in different teams. Then check where tasks depend on each other in chains: that's your critical path, and it's what leadership needs to hear about first to make informed decisions.
In Planyway, the Roadmap view handles most of this on one timeline: epics from multiple projects, milestones across the whole timeline and inside epics, dependencies from any connected space shown as arrows, and a drag and drop interface for moving work.
➡️ Try Planyway free
- Capacity behind the dates. Before you commit an initiative to a quarter, check team availability and resource availability for the teams working on it. Capacity planning at the epic level catches most collisions between ongoing projects. With limited resources, that's often the difference between project success and a missed quarter.
- Milestones that mean something. Releases, external deadlines, funding decisions. Ten milestones per project means nobody notices any of them.
- Status from Jira, not from a slide. Let progress roll up from the work items, so the roadmap reflects reality without anyone updating it by hand. That's what makes tracking progress across teams realistic.
- A rhythm for changing priorities. Priorities shift, so treat the roadmap as dynamic planning, not a fixed document. A short monthly review keeps the roadmap honest, and scenario planning lets you adjust plans before you move real dates.
Where to start
- Write down the three or four things leadership asks about most, usually tied to organizational goals. Those are your top-level items.
- Decide whether they're a hierarchy level, a space or a field.
- On Premium, test the new level on a sandbox, then add it and build a plan in Jira Plans. On Standard, start with a custom field and see how far it takes you.
- Map your existing epics to the new level and close the ones that don't belong anywhere.
- Only then build the multi-project roadmap, with one view per audience. That's what makes it useful for strategic decision making, not just reporting.
If you want to try a cross-project roadmap on your own Jira data, Planyway for Jira has a free trial on the Atlassian Marketplace.
I'm curious how your hierarchy looks: what sits above epics in your Jira, if anything? Tell me in the comments.
