Jira Issue Type Hierarchy: A Practical Guide for Teams
Confused by the Jira issue type hierarchy? Learn to organize Epics, stories, and subtasks for clearer planning and reporting. Read now!
Jira can feel confusing when an Epic contains stories, a story contains subtasks, and another team uses different issue types for similar work. Without a clear hierarchy, reports become unreliable, sprint planning slows down, and people lose track of how daily tasks connect to larger goals.
The problem grows when teams create custom issue types without defining where each one belongs. A “Feature” might sit beside an Epic in one project and beneath it in another. That inconsistency makes boards harder to read and portfolio progress difficult to measure.
Here’s the practical solution: understand Jira’s standard structure, decide which levels your team actually needs, and document clear rules for each issue type. This guide shows you how the hierarchy works, where teams commonly go wrong, and how to create a structure that supports planning without adding unnecessary administration.
Jira Issue Type Hierarchy Explained
Jira issue type hierarchy describes how work items relate to one another, from high-level initiatives to individual subtasks. In a common Jira setup, the structure is Epic → Story, Task, or Bug → Sub-task.
Each level answers a different planning question. An Epic represents a substantial body of work. A story, task, or bug represents a specific piece of delivery work. A sub-task breaks that work into smaller actions for one person or a small group.
The standard Jira structure
- Epic: A large outcome that requires several related issues. Examples include “Launch mobile checkout” or “Improve customer reporting.”
- Story: A user-focused requirement that delivers a recognizable benefit. For example, “As a customer, I want to save my payment method.”
- Task: A defined piece of work that may support a product, technical, operational, or internal goal.
- Bug: A defect that causes expected behavior to fail or produces an incorrect result.
- Sub-task: A smaller action connected to a parent story, task, or bug. Examples include testing, interface design, or deployment preparation.
Stories, tasks, and bugs usually sit at the same working level. They can belong to an Epic, while subtasks belong to one of those standard work items.
Where initiatives and higher levels fit
Large organizations may need a level above Epics. A portfolio structure might look like Initiative → Epic → Story, Task, or Bug → Sub-task.
Jira configurations with Advanced Roadmaps can support additional planning levels, depending on the product edition and administrator settings. Some teams use “Theme,” “Capability,” or “Initiative” above an Epic.
These higher levels should represent meaningful business outcomes. If a team adds several layers simply because the hierarchy looks sophisticated, planning usually becomes slower.
Hierarchy versus issue type schemes
A hierarchy explains how issues relate to one another. An issue type scheme controls which issue types a project can use.
For example, a project may allow Epics, Stories, Tasks, Bugs, and Subtasks. Another project may allow only Tasks and Bugs. The available issue types do not automatically create useful parent-child relationships.
Here’s why: a team can have the correct issue types and still create a confusing structure. The hierarchy needs clear rules, suitable permissions, and consistent usage.
What the hierarchy does not control
The hierarchy does not decide every relationship in Jira. A task can link to another task, block a bug, relate to a requirement, or connect to an external system.
Those links are valuable, but they are different from parent-child relationships. A story’s subtasks describe how the story will be completed. A “blocks” link describes a dependency between separate pieces of work.
How to Design a Practical Work Structure
The best hierarchy reflects how your team plans and delivers work. Start with the way decisions are made, then map each planning question to one issue level.
1. Define the outcome level
Ask what leadership, product managers, or customers need to understand. If the answer is a major outcome spanning several releases, use an Initiative or Epic.
For example, “Reduce checkout abandonment” may be an initiative. It could contain Epics such as “Simplify payment entry,” “Improve error handling,” and “Add guest checkout.”
2. Define the delivery level
Next, identify the work a delivery team can plan, estimate, and complete. Stories, tasks, and bugs usually belong here.
A story should describe a valuable result. A task may describe technical or operational work. A bug should explain the difference between expected and actual behavior.
3. Use subtasks for execution details
Subtasks work well when several actions contribute to one parent issue. A checkout story might include subtasks for interface changes, service updates, automated testing, and release checks.
Use subtasks when the parent issue remains the main planning unit. Create separate stories when each part has its own value, owner, priority, or release decision.
4. Limit custom issue types
Before adding a custom type, ask whether the team needs a different workflow, field set, permission model, or reporting behavior.
If the only difference is a label, a component, a priority, or a field may work better. Ten issue types can create more confusion than five well-defined types.
5. Write a short usage rule
Create a simple rule for each type. For example:
- Epic: Use for work requiring several related delivery issues.
- Story: Use for a customer or stakeholder outcome.
- Task: Use for planned work without a user-facing requirement.
- Bug: Use when existing behavior fails an agreed expectation.
- Sub-task: Use for execution steps within one parent issue.
Place these rules where the team can see them during planning. A short example often prevents more confusion than a long policy.
How Parent-Child Relationships Work in Jira
A parent-child relationship connects a larger work item with the issues needed to complete it. The parent provides context, while the children show delivery progress.
Epic to story, task, or bug
An Epic can group related stories, tasks, and bugs. For example, an Epic called “Mobile account recovery” might contain:
- A story for password reset through email.
- A story for recovery through a verified phone number.
- A task for updating account security messaging.
- A bug for an expired recovery link redirecting incorrectly.
This grouping helps a product manager review progress toward one outcome instead of scanning unrelated issues.
Story or task to subtask
Subtasks divide implementation work. They can have separate assignees, estimates, statuses, and time tracking.
Suppose a story requires a new reporting filter. Its subtasks might cover query logic, interface work, accessibility checks, and quality assurance. The story remains the value-bearing item, while subtasks represent the work needed to complete it.
Parent status and child status
Jira does not always treat parent status as a simple mathematical summary of child statuses. Your workflow, automation, board settings, and reporting rules influence what people see.
A parent may remain “In Progress” while one subtask is complete and another is blocked. That status can be accurate because the overall outcome is still unfinished.
Hierarchy and estimation
Teams should decide where estimates belong. Many Agile teams estimate stories and use subtasks for implementation visibility. Others estimate subtasks and roll those values up for capacity planning.
Choose one approach and apply it consistently. Mixing story points, hours, and informal estimates across levels makes sprint forecasts difficult to interpret.
Common Jira Hierarchy Patterns
Different teams need different levels of detail. The right pattern depends on product complexity, planning horizons, and the number of teams involved.
Pattern one: simple delivery hierarchy
Epic → Story, Task, or Bug → Sub-task
This pattern suits a small product team working from one backlog. It gives the team enough structure for sprint planning without adding portfolio layers.
Example: a ten-person SaaS team may create an Epic for “Billing improvements,” then add stories for invoices, payment retries, and tax settings.
Pattern two: portfolio hierarchy
Initiative → Epic → Story, Task, or Bug → Sub-task
This pattern suits organizations where several teams contribute to a shared business outcome. The Initiative gives leadership a broader view, while Epics remain practical for product planning.
Example: an Initiative called “Expand into Germany” could include Epics for localization, payment methods, legal requirements, and customer support readiness.
Pattern three: technical delivery hierarchy
Epic → Technical task or story → Sub-task
Engineering teams may use technical tasks for architecture, infrastructure, migration, or performance work. These items can sit beside customer-facing stories within one Epic.
For example, a search improvement Epic may include a customer story for better filters and a technical task for indexing changes.
Pattern four: bug-focused structure
Epic or project goal → Bug → Sub-task
Teams managing a large stability effort may group defects under an Epic. A bug can then include subtasks for reproduction, diagnosis, correction, and regression testing.
Use this pattern when defects contribute to a broader goal. Routine bugs may need no Epic at all.
Jira Hierarchy Mistakes to Avoid
Hierarchy problems rarely come from one dramatic configuration error. They usually develop through small exceptions that accumulate over time.
Creating an issue type for every situation
A team may create “Feature,” “Enhancement,” “Request,” “Change,” and “Improvement” even though these terms overlap. People then spend time deciding which label applies.
Start with the smallest useful set. Add a new type only when it changes workflow, ownership, permissions, or reporting.
Using subtasks as independent backlog items
Subtasks depend on their parent. They are poor choices for work that needs separate prioritization or release tracking.
If a task may move to another sprint, receive its own acceptance criteria, or remain valuable after the parent changes, consider creating a separate story or task.
Putting unrelated work under one Epic
An Epic called “Q3 work” may collect unrelated bugs, technical upgrades, and customer requests. It becomes a storage area rather than a meaningful planning unit.
A better Epic describes one outcome, product area, or coherent body of work. For example, “Improve invoice accuracy” gives the team a clearer boundary.
Adding too many hierarchy levels
More levels can make a roadmap look organized while making daily planning harder. If a team cannot explain the difference between a Theme, Capability, Initiative, and Epic, the structure is too complicated.
Keep only the levels that answer distinct planning questions.
Ignoring cross-team dependencies
Parent-child links show structure, while dependency links show coordination needs. A mobile story may depend on an API task in another team’s project.
Use dependency links, shared milestones, and clear ownership so the hierarchy does not hide work that must happen elsewhere.
Reporting and Governance Practices
A hierarchy becomes useful when it supports decisions. Review whether managers can see progress, whether delivery teams can plan clearly, and whether reports reflect real work.
Use roll-up reporting carefully
Progress at an Epic or Initiative level can be calculated using completed issues, estimates, status categories, or manually maintained targets. Each method tells a different story.
For example, five of six issues may be complete, yet the remaining issue could contain the highest-risk work. A simple percentage might look healthy while the outcome remains uncertain.
Review the structure during retrospectives
Ask whether the team created issues at the right level. Did stories become too large? Did subtasks turn into hidden backlog items? Did custom types create debate?
Use these observations to refine your conventions. Hierarchy design should improve as the team learns.
Assign ownership for administration
Someone should own issue type schemes, workflows, fields, and hierarchy settings. Without ownership, every team may make local changes that weaken organization-wide reporting.
Governance does not require heavy approval. A lightweight review can check whether a proposed change solves a recurring problem.
Create examples for onboarding
New team members understand hierarchy faster when they see realistic examples. Show one Epic, three delivery issues, and several subtasks.
Include examples of work that should stay separate. For instance, explain why a release blocker belongs as a linked bug instead of a subtask under an unrelated story.
Jira Issue Hierarchy Solution: ONES.com
ONES.com combines project management and knowledge management in one platform. ONES Project provides Jira-compatible workflows, while ONES Wiki supports shared team knowledge and planning guidance.
For teams comparing a Jira alternative, the practical value comes from keeping hierarchy rules, delivery work, reporting, and team guidance closer together. ONES Project is sold separately from ONES Wiki.
Value Proposition
ONES.com helps teams turn hierarchy conventions into repeatable project workflows. You can keep high-level planning connected to execution while reducing the need for multiple plugins and scattered administration.
Core Capabilities
- Complex hierarchy confusion → Custom workflows and fields → Teams can represent different planning needs with clearer issue details and consistent status paths.
- Unclear sprint execution → Sprint management → Teams can plan stories, tasks, bugs, and subtasks within defined sprint boundaries.
- Manual recurring actions → Automation → Repetitive transitions, assignments, and notifications can follow configured rules instead of relying on memory.
- Weak visibility into delivery progress → Built-in reporting → Managers and delivery teams can review progress, workload, and issue movement in one project environment.
- Too many disconnected plugins → Native project capabilities → Teams can reduce dependency on add-ons for common planning, workflow, and reporting needs.
- Migration concerns → Jira-compatible workflows → Teams familiar with Jira-style issue management can preserve recognizable planning patterns while evaluating a different platform.
- Restricted deployment requirements → On-premise, private cloud, and air-gapped deployment options → Organizations with tighter infrastructure controls can select a deployment model that fits their operating environment.
- Different team processes → Custom workflows and fields → Product, engineering, support, and operations teams can adapt project handling without forcing every group into an identical process.
Application Scenarios
Growing product organization: A product group may use Epics for product outcomes, stories for customer value, technical tasks for engineering work, and subtasks for implementation. Built-in reporting can help leaders review progress without asking each team for a separate update.
Regulated engineering environment: An engineering organization may need on-premise or air-gapped deployment. It can use familiar Jira-compatible workflows while keeping project operations within its selected infrastructure.
Multiple departments with different workflows: A company may use one workflow for product delivery and another for internal operations. Custom fields and workflow rules can preserve the distinction while keeping project management in one platform.
Common Challenges
Challenge: The hierarchy is too complicated
Problem: People cannot explain when to use an Initiative, Epic, Feature, Story, Task, or Sub-task.
Solution: Remove overlapping levels and write one sentence describing the purpose of every remaining type. Test the rules with real planning examples.
Challenge: Teams use the same issue type differently
Problem: One team uses Tasks for technical work, while another uses Tasks for customer requests. Organization-wide reports become difficult to interpret.
Solution: Define shared meanings for common types, then allow team-specific fields or workflows where genuine differences exist.
Challenge: Progress reports look better than reality
Problem: Many low-effort issues are complete, while one high-risk issue remains unfinished. A completion percentage hides the risk.
Solution: Combine completion metrics with blocked status, remaining estimates, risk indicators, and milestone reviews.
Challenge: Subtasks hide important work
Problem: A subtask contains a separate deliverable, yet it remains invisible in broader planning discussions.
Solution: Promote it to a story or task when it needs independent ownership, priority, estimation, or release visibility.
Challenge: Cross-team work is difficult to track
Problem: Parent-child relationships show what belongs together, but they do not reveal every dependency.
Solution: Use dependency links, clear ownership, shared milestones, and regular coordination reviews alongside the hierarchy.
FAQs
What is the default Jira issue hierarchy?
The common Jira structure is Epic, followed by Story, Task, or Bug, followed by Sub-task. An Epic groups related delivery work, while a subtask breaks one delivery item into smaller actions. Some organizations add Initiative or another portfolio level above Epics through Advanced Roadmaps or customized configuration.
Are Stories, Tasks, and Bugs at the same hierarchy level?
Usually, yes. Stories, Tasks, and Bugs generally represent the main delivery level beneath an Epic. They differ in purpose rather than rank. A story describes a valuable requirement, a task describes planned work, and a bug describes a defect. Your workflows and reporting rules may treat them differently.
Can a subtask have another subtask?
Jira generally treats subtasks as the lowest standard level, so a subtask cannot usually contain another subtask. If the work needs another layer, create a separate issue at the appropriate level or reconsider whether the parent should be a story, task, or Epic.
When should I create a new issue type?
Create one when the work needs a genuinely different workflow, field set, permission model, or reporting treatment. Avoid creating a new type only because a team prefers a different label. A field, component, label, or workflow transition may solve the problem with less complexity.
Should every story contain subtasks?
No. Small stories may be clear enough without subtasks. Add them when multiple people, disciplines, or execution steps must coordinate around one parent issue. If the child work needs separate prioritization or release tracking, create an independent story or task instead.
How many hierarchy levels should a team use?
Use the fewest levels that answer your planning questions. A small team may need only Epics, Stories or Tasks, Bugs, and Subtasks. A large organization may benefit from an Initiative level above Epics. If people frequently debate where work belongs, simplify the structure and clarify the rules.
Conclusion
A practical Jira hierarchy connects business outcomes with the work people complete each day. The usual structure is Epic, Story, Task, or Bug, followed by Sub-task, with an Initiative level added only when portfolio planning requires it.
Keep each level purposeful, distinguish parent-child relationships from dependencies, and avoid custom issue types that add labels without improving workflow or reporting. Review the structure during retrospectives so it continues to match how your team works.
But here’s the truth: a hierarchy alone cannot repair unclear ownership or weak planning habits. Define simple rules, use concrete examples, and choose project management software that supports those rules. With that foundation, your Jira structure—or a Jira alternative such as ONES Project—can make delivery easier to understand and manage.