Jira Align doesn’t have one hierarchy — it has two, and the reason two Atlassian Community threads exist asking for “the definitions” (one with 50,758 views, one with 1,921) is that neither Atlassian’s help docs nor its marketing page lay both hierarchies out side by side. One hierarchy is organizational — who’s on what team. The other is about work items — what kind of issue something is. They share a term (“Portfolio” means different things in each) and they connect, but they are not the same list. This page pulls both together from Jira Align’s own documentation and named Community sources — Crosstown Tech has never run Jira Align and isn’t pretending otherwise.

Wait — is it “Jira Align” or “Atlassian Align”?

Quickly, because it affects what you search: every hierarchy doc this page cites lives on help.jiraalign.com and says “Jira Align.” The drift is confined to Atlassian’s own marketing page, where — checked live today — the HTML title reads “Atlassian Align | Enterprise Portfolio Execution,” but the same page’s logo, navigation, and footer still say “Jira Align.” Full detail on that split: What is Jira Align? For everything below, “Jira Align” is the working name.

Why “the hierarchy” is really two hierarchies

Search “Jira Align hierarchy” and you land on two different kinds of answers, because two different structures both go by that name:

  1. The organizational hierarchy — who belongs to what team, and how teams roll up. Four levels: Portfolio → Solution → Program → Team.
  2. The work hierarchy — what kind of issue something is, and what size of work it represents. At minimum five levels, optionally six: Strategy → Theme → Epic → (Capability) → Feature → Story.

That overlap is exactly what a 1,921-view Atlassian Community question ran into: the asker wanted plain definitions for “all 14 possibilities in the 6-layer hierarchy,” and the Atlassian replies pointed to a glossary and a SAFe methodology reference rather than answering directly on the thread — because the real answer spans two separate hierarchies, not one glossary entry per term.

The organizational hierarchy: Portfolio, Solution, Program, Team

Per Jira Align’s own organizational structure and team types documentation:

  • Portfolio — “a distinct line of business that includes its own organizational structure with its own executives, product management, and development teams.” Most organizations run one; larger ones may run several, typically after acquisitions.
  • Solution — “a team structure used to group programs when a multi-program consolidated view is required routinely.” Atlassian’s own example: grouping a “Business” program and a “Consumer” program under a shared “Enablers” solution for combined reporting.
  • Program — “also called a release train in SAFe,” a program is “a group of teams that work on a common backlog to deliver features.” Multiple Teams roll up into one Program, and the Program backlog sets the priority order.
  • Team — the base level everyone belongs to. Per the team-types doc, an Agile team’s members “can access all the team’s data and view work for other teams in the same program,” while a Portfolio team sits at the top of this list with “some visibility into other programs and portfolios.”

This is the hierarchy that answers “whose backlog is this” and “who can see what.” It’s a people-and-structure question, not a work-item question.

The work hierarchy: Strategy, Theme, Epic, Capability, Feature, Story

Per a named Atlassian Community explainer with 42,777 views, “Jira Align enables at minimum a five-level hierarchy: Strategy → Theme → Epic → Feature → Story,” with Capability optionally inserted between Epic and Feature for six. Working top-down, per Jira Align’s own docs and a second Community explainer with 50,758 views:

  • Strategy — the top. Built in Jira Align’s strategic backlog from an organization’s mission, vision, and values, per Jira Align’s strategic-hierarchy guide.
  • Theme — “the tip of the spear for the work hierarchy” and “a linchpin between enterprise strategy and the work,” meant to span many Program Increments or even years.
  • Epic — “large bodies of work intended to deliver value in support of a Theme,” often carrying its own lean business case and budget.
  • Capability (optional) — “solutions that span across Agile Release Trains” — bigger than a Feature, but still sized to fit one Program Increment. This is the level that exists specifically for organizations running multiple Programs under a Solution.
  • Feature — “the result of splitting Epics or Capabilities and sizing the work to fit within one Program Increment (12 weeks).” This is the level that syncs down into an ordinary Jira Epic.
  • Story — the team-level unit, “defined with Acceptance Criteria,” that a Feature gets broken into for sprint-level delivery — the same object type as a Jira Story.

Note the connective tissue back to the organizational hierarchy: Themes and Epics are typically owned at the Portfolio altitude, Capabilities at the Solution altitude, Features at the Program altitude, and Stories at the Team altitude. The two hierarchies are separate lists, but each work-item level is planned at a matching organizational level.

Which levels does your organization actually need?

Fewer than six, for most organizations. Jira Align’s own default is five levels (no Capability), and Capability exists specifically to serve companies running Solutions that group multiple Programs — a scale problem, not a universal requirement. Beyond the presets, a named Atlassian Team member’s 2024 Community post on custom hierarchies confirms Jira Align lets enterprises build their own levels rather than use the defaults, because “large enterprises face unique challenges within their business context” that a fixed set of objects doesn’t cover.

Practically: if your organization isn’t yet running multiple Programs or Solutions — Jira Align itself is built for “hundreds to thousands of users,” per the sizing detail on Jira Align vs Jira — Epic, Feature, and Story cover most day-to-day planning. Theme and Strategy matter once there’s an actual portfolio-level strategy to connect work to; Capability and Solution matter once there’s more than one Program’s worth of teams sharing a roadmap. Add levels as that structure appears, not before — an unused hierarchy level is just an empty dropdown nobody fills in correctly.

This is also, honestly, the one place on this page where Crosstown Tech’s founder has direct professional background: five-plus years building Structure, a Jira hierarchy and portfolio-data product at ALM Works/Tempo — hierarchy-over-portfolio-data is a domain he’s spent real time in, though that’s Jira hierarchy tooling, not hands-on Jira Align experience specifically.

If what you actually need is smaller than any of this

Jira Align’s hierarchy exists to serve enterprise portfolio planning across dozens of teams. If your actual problem is much narrower — someone outside Jira just needs a readable status update, not a six-level hierarchy to maintain — that’s a different, cheaper problem. Jira reports for stakeholders who don’t use Jira and a Jira status report without a login cover that directly. And for the basics of what Jira Align is, what it costs, and how it relates to plain Jira, see What is Jira Align?, Jira Align vs Jira, and Jira Align pricing. And once the hierarchy is settled, the next thing enterprises usually ask for is historical and baseline data out of Jira Align — seeing what changed since PI planning started, not just the current state.

If you landed here searching for a hierarchy level above Epic but you’re running plain Jira Software, not Jira Align, see a hierarchy level above Epic in Jira instead — a different product, a different price point, and a different (much narrower) native capability.