Jira Hierarchy Beyond Epic: Initiatives, Themes, and Custom Levels in 2026

Jira's default hierarchy stops at Epic → Story / Bug / Task → Sub-task. To add Initiatives, Themes, or custom levels above Epic you need either Jira Premium's custom issue type hierarchy feature (which unlocks seven levels above Epic site-wide) or a Marketplace app — Structure, BigPicture, or Foundation — that manages a parallel hierarchy. Here's what each option actually lets you do, what it costs, and how to pick.

What's in Jira's default hierarchy?

Out of the box, every Jira Cloud site ships with a fixed three-level issue hierarchy: Epic → Story / Bug / Task → Sub-task. Epic sits at the top, the standard issue types sit in the middle, and Sub-task is pinned to the bottom. This applies to both Team-Managed and Company-Managed projects, and it applies across every edition from Free through Standard.

The hierarchy is baked into how Jira's search, boards, and reports work. The JQL keyword parent resolves against it. Board swimlanes group by it. The backlog view on a Scrum board is built on top of it. That tight coupling is why Atlassian has been cautious about extending it — every change ripples through every project's native view.

The ceiling is real. If your quarterly plan has Themes that contain Initiatives that contain Epics, there is no native place in a Standard Jira site to express that. You can put the words “Theme” in a label or a custom field, but Jira's native reporting will not treat those as a hierarchy level, and you cannot roll work up across them in a board or plan.

Why do teams need levels above Epic?

Almost every team that outgrows a single Scrum project hits the same wall: Epics are too granular for executive reporting. A VP does not want to scroll through sixty Epics — they want to see eight Initiatives or three Themes and understand which are on track. That mismatch is the single biggest reason teams adopt a portfolio tool.

Four recurring use cases drive the need for levels above Epic. Quarterly theme tracking — executives committing the organization to “Customer Retention” or “Platform Reliability” for a quarter and wanting to see which Epics feed each theme. OKR alignment — Objectives and Key Results live above the delivery tier and need to roll up progress from the Epics underneath them. Executive reporting — program managers producing a status deck once a month need a tier that maps to business outcomes, not sprint tasks. SAFe Program Increment objectives — at SAFe maturity, teams explicitly track Portfolio Epics, Capabilities, Features, and Stories as four separate hierarchy tiers.

The PMI definition of a strategic Initiative describes it as a discrete, time-bounded effort with measurable outcomes that ladders up to strategic objectives — which is exactly the tier Jira's native hierarchy is missing.

How Jira Premium's custom issue type hierarchy works

Jira Premium includes a feature called custom issue type hierarchy that lets Jira site administrators add up to seven tiers above Epic. You open the global issue-type-hierarchy settings page, create new issue types (Initiative, Theme, Capability, whatever you like), and drop them into ordered levels. Those levels are site-wide — every project that uses those issue types inherits them.

What this unlocks: proper parent/child relationships in native Jira Plans (Premium's advanced roadmap), correct roll-up of dates and progress across the full tier, JQL that can query by hierarchy level, and timeline views that visibly group work under the higher tier. For teams that need two or three levels above Epic and are already paying for Premium, it is genuinely useful and costs nothing extra.

What it does not do. It does not support non-issue levels — every node must be a real Jira issue, so using folders or program headers means creating placeholder issues nobody wants to triage. It has weak cross-project visibility — the hierarchy exists globally, but a single Plan in Jira Plans struggles to roll up cleanly when the tree spans many projects. It does not support drag-parenting in Plans the way a dedicated portfolio tool does. And it is gated behind Jira Premium pricing, which roughly doubles the per-user cost compared with Standard.

How Structure builds hierarchies

Structure by Tempo is the category incumbent and takes a different approach. Instead of modifying Jira's native hierarchy, it builds a parallel hierarchy on top. Each Structure is an independent tree that can pull in any Jira issues via generators — rules that say “insert every Epic in Project X,” “then under each Epic, insert its Stories,” “then memo folders for grouping.”

Structure's superpower is its Expr formula language. It has 100+ functions for weighted roll-ups, custom-field arithmetic, conditional formatting, and scripted aggregations. Want a column that shows “forecast finish based on remaining story points and velocity, weighted by risk”? Expr can express that. Nothing else in the Jira ecosystem matches it for scripted reporting.

Hierarchy-wise, Structure supports unlimited depth, mixed issue types, and folder-like non-issue nodes. It spans projects natively because it treats the Structure itself as the scope, not the project. The trade-off: Structure is a Connect app, so your hierarchy metadata lives on Tempo-operated servers, and since March 2026 rate-limit changes, its polling-based refresh model consumes Jira API points that Forge event triggers do not.

How BigPicture builds hierarchies

BigPicture by Appfire takes a more opinionated, WBS-oriented stance. Hierarchies in BigPicture are called Boxes, and they come with a pre-configured tier system — Program, Project, Phase, Iteration — that maps cleanly onto traditional project management frameworks. You can customize, but the defaults assume you are running a WBS-style breakdown rather than a pure agile portfolio.

BigPicture's hierarchy is task-like: every node, including synthetic ones, behaves like a task with start dates, end dates, dependencies, and resource allocations. This makes it excellent for traditional PMO reporting — critical path analysis, resource histograms, baseline-vs-actual — and it is the reason BigPicture is popular with teams migrating from Microsoft Project or Primavera.

The trade-off is rigidity. The Box hierarchy model is powerful but opinionated; teams that want a lightweight spreadsheet-like grouping often find it heavier than they need. Like Structure, BigPicture is a Connect app, so data residency and API rate limits follow the same pattern — data lives on Appfire servers and refresh costs Jira API points.

How Foundation Lenses build hierarchies

Foundation Lenses take a third approach. A Lens is a customizable hierarchical view that pulls Jira issues from any projects into a single tree. Hierarchies are unlimited-depth, mixed-type, and fully drag-and-drop — you can grab any row and re-parent it, and the change reflects back to Jira through the standard parent-link API.

Three features make Foundation distinct. Sync Agents (JQL Insert, Child Extend, Linked Items Extend) auto-populate and maintain hierarchy content from JQL queries or Jira relationships, so the tree stays fresh without manual curation. Flex Items are non-issue hierarchy nodes that exist only inside Foundation — ideal for OKR headers, portfolio buckets, or program section labels that should not become real Jira issues. And because Foundation is built on Atlassian Forge, hierarchy updates arrive through free product-event triggers instead of polling, so a Lens refreshes in seconds without consuming your Jira API rate-limit budget.

Foundation supports unlimited hierarchy depth per Lens with no per-level feature gating, and the same Lens can span as many Jira projects as you like. The MVP targets 1,000 issues per Lens; larger portfolios split naturally across multiple scoped Lenses.

What to call each level: Theme, Initiative, Capability, or Goal?

Naming is more than cosmetic — it tells your team what each tier means and how to populate it. Four common frameworks give you a starting vocabulary. SAFe uses Strategic Theme → Portfolio Epic → Capability → Feature → Story → Task, designed around the Program Increment cadence. OKRs use Objective → Key Result → Epic → Story, with Objectives typically quarterly. LeSS (Large-Scale Scrum) keeps it flat — Product Backlog Item → Task — and pushes strategic layering into the product vision document. Spotify-model squads often use Mission → Bet → Epic → Story, with Missions lasting six to twelve months.

A pragmatic mapping for most mid-size teams: use Theme for annual or multi-quarter strategic buckets, Initiative for cross-team efforts spanning one to three quarters, Epic for the work a single team delivers over several sprints, Story for the work a single team delivers in one sprint, and Sub-task for tactical breakdown within a Story. If your org already uses SAFe, OKR, or LeSS vocabulary, inherit that. Do not invent new words for tiers that already have well-understood names.

How to migrate hierarchies between tools

Migrating from Jira Premium's custom hierarchy, Structure, or BigPicture to Foundation — or between those tools — follows a predictable pattern. Your Jira issues stay exactly where they are; only the app-specific scaffolding has to move. Issue links preserve cleanly because they live in Jira itself. Parent/child relationships preserve if the target tool can read Jira's native parent link or the source tool's hierarchy API.

Flex Items and folders translate partially. Structure folders and BigPicture Boxes can be imported into Foundation as Flex Items; Jira Premium's issue-typed higher tiers stay in Jira (they are real issues) and Foundation simply references them. What does not carry over are formulas. Structure Expr formulas have no equivalent in Jira Premium's native hierarchy and no equivalent in Foundation today — they have to be rewritten or deferred until Foundation's formula engine ships.

The common migration pattern: run both tools side-by-side for two to four weeks, validate the hierarchy in the target, rebuild any critical formulas or generators in the new syntax, train the team, then cancel the source tool. Foundation's Structure and BigPicture importers and Jira Plans comparison walk through the exact mechanics.

What permissions matter for hierarchy-wide reporting?

Cross-project hierarchies raise a permission question Jira's native views never have to answer: what do you show a user who can only browse some of the projects in the tree? Get this wrong and you leak confidential issue keys through a parent node a user should never see. Get it too strict and users see half-empty trees with unexplained gaps.

The right model is browse-permission filtering: the tool enforces Jira's native BROWSE_PROJECTS permission per issue and hides any node the current user cannot browse in Jira. Foundation, Structure, and BigPicture all do this, but they handle hidden-parent cascade differently. Foundation fails closed: if a parent is hidden, its descendants are hidden too, even if the user could browse them individually — on the principle that exposing an orphaned child is worse than hiding a browsable one.

A second consideration is app-level access control: who can edit the hierarchy itself, as distinct from who can browse issues. Foundation has a four-tier permission model (view, edit, edit-generators, control) separate from Jira's project permissions. If your organization has portfolio managers who should curate the hierarchy without having edit rights on every underlying project, that separation matters.

How to measure hierarchy health

A hierarchy that exists on paper but is not maintained becomes worse than having no hierarchy — people trust it, then discover it was stale. Three metrics signal whether your hierarchy is healthy. Orphan count: Epics or Stories that are not linked to a parent above them. Anything above zero is technical debt — either the work is not strategic (in which case it should not be in the portfolio) or the hierarchy is missing a link.

Dead-end Initiatives: top-tier nodes that have no descendants, or whose descendants are all Done. These are either completed initiatives that should be archived or proposed initiatives that never got staffed. Either way, they pollute the view. Ratio of Themes to Epics: a healthy portfolio typically has three to ten Epics per Initiative and three to seven Initiatives per Theme. Ratios outside that range mean either tiers are redundant (too few children) or too coarse (too many children).

Foundation surfaces these metrics automatically in its portfolio Lens; in native Jira Plans you have to assemble them yourself via JQL and saved filters. Whatever tool you use, make the check monthly — hierarchy health is one of those things that is trivial to audit regularly and painful to repair after a year of neglect.

Feature comparison

Capability	Jira Standard	Jira Premium	Structure	BigPicture	Foundation
Levels above Epic	0	Up to 7	Unlimited	Unlimited	Unlimited
Non-issue nodes (folders)	No	No	Yes (folders, memos)	Yes (Boxes)	Yes (Flex Items)
Cross-project hierarchy	Limited	Limited (native Plans)	Yes	Yes	Yes
Drag-and-drop reparent	No	Partial (Plans)	Yes	Yes	Yes
Formula engine	No	No	Yes (Expr, 100+ fns)	Limited	Roadmap (Q1 2027)
Refresh mechanism	Native	Native	Polling (Connect)	Polling (Connect)	Event-driven (Forge)
Data residency	Atlassian cloud	Atlassian cloud	Tempo servers	Appfire servers	Atlassian cloud (Forge)
Cost above baseline Jira	—	~2× Standard	Per-user add-on	Per-user add-on	Free 1–10, below Structure above

How we evaluated hierarchy options

We build Foundation, so treat us as a biased source and verify anything load-bearing. The Jira Premium capabilities cited here come from Atlassian's own documentation and from building a seven-level hierarchy on a Premium test site in March 2026. The Structure and BigPicture capabilities come from their public documentation, their Marketplace listings, and side-by-side testing on 500-issue portfolios across three Jira projects over four weeks. The Foundation capabilities are what ships in the current build.

What we tested: building a four-tier Theme → Initiative → Epic → Story hierarchy in each tool, populating it with JQL or manual addition, testing drag-and-drop reparenting, measuring refresh latency after a Jira issue change, testing permission-aware rendering for a user with partial browse access, and importing an existing Structure into Foundation. What we did not test: plans above 5,000 items (exceeds Foundation MVP scope), Structure on Jira Data Center (Foundation is Cloud-only), and deep Expr formulas (Foundation has no formula engine today, so a direct comparison is not meaningful until Q1 2027).

Frequently asked questions

Can I add Themes above Epic on Jira Standard?

Not natively. Jira Standard caps the issue hierarchy at Epic → Story/Bug/Task → Sub-task and does not expose the custom issue type hierarchy configuration. To add Themes, Initiatives, or any level above Epic on Jira Standard you need either to upgrade to Jira Premium (which unlocks up to seven custom levels above Epic) or install a Marketplace app such as Foundation, Structure, or BigPicture that manages its own hierarchy layer on top of Jira.

What is the difference between an Initiative and a Theme?

Themes are the highest strategic bucket — typically annual or multi-quarter priorities like "Customer Retention" or "Platform Reliability". Initiatives sit one level below and represent concrete cross-team efforts that ladder up to a theme, usually lasting one to three quarters. Epics deliver the work inside an Initiative. Different frameworks name these tiers differently: SAFe uses Portfolio Epic / Capability / Feature / Story; OKR frameworks use Objective / Key Result; PMI treats an Initiative as a discrete strategic plan with defined outcomes.

How many hierarchy levels should a team use?

Most teams land on three to five levels between the top strategic tier and the delivery tier. Any more than seven becomes operational noise — nobody meaningfully navigates an eight-level tree. Start with the levels your reporting actually needs: if executives ask "which Themes are on track?" you need a Theme tier; if nobody asks that question, skip it. The most common productive shape is Theme → Initiative → Epic → Story → Sub-task, which covers quarterly planning, program execution, and team delivery in one structure.

Can I have different hierarchies per project?

In Jira Premium, the custom issue type hierarchy is site-wide — every project shares the same tier definitions, though individual projects can use a subset. In Marketplace apps like Foundation, hierarchies are per-Lens rather than per-project, so you can run a five-level portfolio Lens across your strategic projects while a delivery team keeps a flat two-level Lens for sprint work. Structure and BigPicture both support per-structure hierarchies too.

What happens to Epics when you move to a new hierarchy tool?

Your Jira Epics stay exactly where they are — they are Jira issues and nothing outside Jira can delete or move them. A hierarchy app like Foundation references Epics by their Jira issue key and adds parent/child relationships in its own metadata. When you import from Structure or BigPicture, Epics keep their issue keys, custom field values, comments, and work log. Only the app-specific scaffolding (generators, formulas, folders) has to be rebuilt in the new tool.

Can I have non-issue hierarchy levels, like folders?

Not in native Jira — every node in Jira's hierarchy must be a real issue type. Foundation addresses this with Flex Items: organizational nodes that exist only inside a Lens and are never written to Jira. Structure has folders and memos; BigPicture has similar "box" abstractions. These are useful for portfolio buckets, OKR headers, program section labels, or temporary sort containers that would otherwise pollute Jira with dozens of placeholder issues.

How do sub-tasks fit into a portfolio view?

Sub-tasks live at the bottom of every hierarchy and usually do not belong in a portfolio or quarterly planning view — they are execution detail. Most portfolio Lenses stop at the Story or Epic level so executives see strategic progress without drowning in sub-task noise. Foundation, Structure, and BigPicture all let you filter sub-tasks out per view while keeping them accessible when you need to drill down into a single Story.

Does hierarchy depth affect performance?

Tree depth itself is cheap — rendering a seven-level tree is not meaningfully slower than a three-level tree. What matters is node count and refresh frequency. Jira Plans slows on plans above ~2,000 items. Structure and BigPicture start to feel heavy above ~10,000 items in a single hierarchy. Foundation targets 1,000 items per Lens in its MVP and uses an event-driven cache to keep reads fast. For portfolios above 10,000 items, split the hierarchy into multiple scoped views instead of one giant tree.