Jira Hierarchy: Levels, Structure & Best Practices
Jira hierarchy looks simple — until you try to put a Task under a Story and Jira won’t let you 😅.
In this guide, we’ve rounded up the most important things to know about Jira hierarchy, based on the questions that come up most often in the Atlassian Community from Jira users.. We’ll look at the common limitations, clear up the confusing parts, and share practical ways to work around them.
What is Jira hierarchy?
Jira hierarchy is the parent-child structure that shows how a large piece of work is broken down into smaller, more manageable items.
The important thing to remember is that hierarchy in Jira is about scope and relationships between work items.
Jira hierarchy levels at a glance
Before we get into the details, here’s the easiest way to understand the standard Jira hierarchy levels:
| Level | Jira work type | What it represents |
|---|---|---|
| Above Epic | Initiative or custom type | A strategic goal spanning several Epics |
| Level 1 | Epic | A large deliverable or body of work |
| Level 0 | Story, Task, or Bug | Work completed by a team |
| Level −1 | Sub task | A smaller step needed to complete a standard item |
The hierarchy moves from broad goals to specific actions. Initiatives group several Epics, Epics contain Stories, Tasks, and Bugs, and those items can be broken into Subtasks.
Stories, Tasks, and Bugs are peers. They sit at the same level, so a Task does not normally sit underneath a Story.
Jira Premium and Enterprise users can create custom issue types on the levels above Epic, but for most teams, the default hierarchy levels are enough.
Let’s see how Agile Jira hierarchy works in practice:
Initiative: Improve trial-to-paid conversion
└── Epic: Create a guided product onboarding experience
├── Story: As a new customer, I want a setup checklist
│ ├── Subtask: Design the checklist component
│ └── Subtask: Write automated tests
├── Task: Implement onboarding analytics
│ └── Subtask: Add event tracking
└── Bug: Checklist progress resets after logout
Jira project hierarchy vs work-item hierarchy
Another common source of confusion is the difference between a Jira project hierarchy and a work-item hierarchy.
A Jira project — called a “space” is a container for work. It is not normally a hierarchy level above an Epic.
A single Jira project can contain many Epics, along with their Stories, Tasks, Bugs, and Subtasks. The project tells you where the work is managed, while the hierarchy shows how that work is connected.
For example:
Project: Customer Portal
├── Epic: Improve account security
│ ├── Story: Add two-factor authentication
│ └── Task: Update security documentation
└── Epic: Simplify profile management
├── Story: Let users update contact details
└── Bug: Profile image fails to upload
Depending on your Jira configuration, an Epic and its children may be managed within the same project, or related work may be spread across several projects. Higher-level items such as Initiatives can then connect Epics from different teams or projects under one strategic goal.
For example:
Initiative: Improve customer experience
├── Epic in Product project: Redesign onboarding
├── Epic in Support project: Improve help center
└── Epic in Marketing project: Create customer education campaign
Teams sometimes create a new Jira project when what they really need is another Epic, an additional hierarchy level, or simply a better cross-project view.
A useful way to decide is:
- Create a new project when the work needs separate permissions, compliance and approval workflows, settings, or team ownership.
- Create a new Epic when you need to group related work around one large deliverable.
- Add custom hierarchy levels when several Epics contribute to the same broader objective.
- Use a portfolio or cross-project view when the structure already exists but is difficult to see in one place.
How to configure hierarchy in Jira Cloud
To view your Jira hierarchy, go to:
Settings → Work items → Work type hierarchy
Admins can review work types, rename levels to match company terminology, and—on Jira Premium or Enterprise—add custom Jira hierarchies above Epic.
For example:
Initiative
└── Epic
└── Story, Task, or Bug
└── Subtask
Custom levels should solve a clear planning problem. Adding levels simply because you can often makes reporting, ownership and team's workflow harder.
Important: Changing hierarchy levels may break existing parent-child issue relationships and cannot be easily undone.
Please note that you can configure custom hierarchy levels only in company-managed Jira projects. In team-managed projects, the default hierarchy strucutre Epic → Story/Task → Subtask cannot be changed natively, so you’ll need to use issue links or Jira Plans to organize larger bodies of work.
How to view hierarchy in Jira
Jira software offers several ways to view how Epics, Stories, Tasks, Bugs, and Subtasks connect in a consistent issue hierarchy.
Individual work items
Open an item to see its parent, multiple sub tasks, links, and dependencies. This works well for quick context, but not for reviewing an extended Jira hierarchy.
Backlog and timeline
The backlog helps teams organize work within a project, while the timeline shows how larger items are scheduled. Both are useful, but cross-project hierarchy can still be difficult to see.
Jira Plans
Jira Premium users can use Plans to combine multiple projects, help teams organize related tasks with custom levels above Epic, track multiple initiatives, and coordinate efforts in complex workflows.
Planyway plugin – Table View
Planyway Table View can bring related Jira work into one expandable table, making it easier to see parent-child relationships, compare key details, update items, and manage work across several projects without constantly switching between screens. It lets you:
- See the work breakdown instead of a flat list.
- Bring multiple Jira projects into one view.
- Edit items without opening them.
- Reorder work while keeping Jira rank in sync.
Its timeline for project management also shows how work unfolds over time, helping teams track progress, compare schedules, and spot gaps.
Search and JQL
JQL can find items by parent, Epic, project, status, or assignee, but results often appear as a flat list. Returning a complete hierarchy from Initiative to Subtask may require several queries or filters.
The hierarchy may exist in Jira, but that doesn’t mean it is easy to browse and update as one clear work breakdown.
Native Jira vs Plans vs Planyway Table View
Choose based on your needs: Native Jira suits everyday team planning, Plans supports portfolio-level work for teams managing complex projects, and Planyway makes cross-project hierarchy easier to manage either in a spreadsheet-style view and advanced roadmaps.
| Need | Native Jira | Jira Plans | Planyway Table View |
|---|---|---|---|
| Basic Epic-to-Subtask hierarchy | Good fit | Good fit | Good fit |
| Add levels above Epic | Requires Premium or Enterprise configuration | Yes | Displays Native Jira structure (coming soon) |
| See several projects together | Limited | Yes | Yes |
| Browse work as a compact tree table | Depends on the view | Available within the planning experience | Core purpose |
| Edit dates from the hierarchy list | Depends on the view | Supported within plan workflows | Inline editing |
| Drag and reorder Jira-ranked work | Usually handled through boards or backlogs | Planning tools are available | Rank stays synchronized with Jira |
Five common Jira hierarchy problems—and how to fix them
➡️ “I can’t put a Task under a Story”
Stories and Tasks sit at the same level, so one cannot normally be the parent of the other.
Fix: Use a Subtask, keep both under the same Epic, or connect them with an issue link.
➡️ “I need another level between Epic and Subtask”
Jira mainly supports custom levels above Epic, not between standard work items and sub task level.
Fix: Use Epics, Subtasks, labels, components, or issue links to organize the work.
➡️ “I can’t see the full hierarchy as a tree”
Jira stores parent-child relationships, but many views show only part of the structure or display items as a flat list.
Fix: Use Jira Plans, Planyway, or combine backlog, timeline, and search views.
➡️ “My work spans several Jira projects”
Many native views focus on one project, board, or team at a time.
Fix: Use Plans, Planyway, shared filters, dashboards, or cross-project boards.
➡️ “JQL doesn’t return the full hierarchy”
JQL may find direct children without automatically returning every nested descendant.
Fix: Use multiple queries, saved filters, or Jira Plans
Conclusion
A good Jira's issue hierarchy should make work easier to understand for projects managers and other users. If teams need a diagram just to remember where an item belongs, the structure may be more complicated than necessary.
- Use only the hierarchy levels you genuinely need.
- Define what “done” means at each level.
- Use issue links—not hierarchy—to track dependencies.
- Keep Story and Task definitions consistent.
- Give every Epic a measurable outcome.
- Create a new project only when you need separate workflows, permissions, or ownership.
- Review existing relationships before changing the hierarchy.
Keep the structure simple and consistent. When Jira’s views feel too flat, especially for multiple teams and projects, Planyway Table View and timeline can help you browse, update, schedule, and track work in a structured but flexible hierarchy.
Was this helpful?
Thanks!
Mary from Planyway
2 comments