Jira issue types: how to structure your hierarchy

How smoothly your team tracks progress through Jira later depends on how well you structure the work now. That structure comes down to issue types — the basic elements Jira uses to manage work, from a two-line bug fix to a company-wide initiative. Get the types and the hierarchy right, and sprints, reports, project progress, and handoffs between teams stay simple, and it's easier to prioritize work when priorities shift.

This guide walks through the five default issue types, when a custom issue type earns its place instead of a field, and how Jira's hierarchy works above Epic and below it. It covers where team-managed and company-managed setups pull in different directions, the one case where software and service teams run into the same problem from opposite sides, and a short checklist for what's worth deciding before you open the admin panel.

TL;DR

• An issue type is a hard link to a specific workflow, a specific set of context fields, and a specific spot in your hierarchical structure. Most of the confusion comes from treating it as decoration instead of wiring.
• Not every change related to Jira Issues costs the same to undo. Adding a subtask or a field is free. Renaming an Epic site-wide, inserting a hierarchy level, or deleting an issue type that already has data on it is not.
• The fix is the same whether you run Jira software or a service desk: fewer issue types, more fields and workflow steps inside the ones you already have.

What is a Jira issue?

An issue is the basic unit of Jira project tracking that helps teams document, discuss, and monitor progress on individual work items. It's one thing someone is responsible for, with a status that moves as the work does.

FYI: Atlassian's 2024–2025 rename brought some changes: “issue” became “work item,” and “issue type” became “work type”. The underlying system didn’t change, and most admin screens, apps, and forum threads still say “issue type”. So that's the term we use in this guide.

What an issue type actually controls

By picking an issue type, you pick three things at once: 

• Workflow — which statuses and transitions the issue has.
• Fields — which fields are shown.
• Hierarchy level — where the issue sits in the hierarchy: Epic → Story → Sub-task, etc.

A Workflow Scheme maps one workflow to each type, so two categories of request that live under the same type are forced through the same statuses and transitions, even if their real-world processes look completely different. A field can be scoped to appear only for specific issue types through its context fields setting: a custom field you added to Bug never shows up on a Task, and the same goes for a time tracking field scoped only to Task.

Everything in the sections below is a consequence of this tripwire. Once you see issue type as “workflow plus fields plus level”, Jira’s quirks stop catching you off guard.

Issue types in Jira: the five defaults at a glance

Which types show up when you open a new space depends on the template you picked — one built for agile teams running agile development, another for a business or service desk. Whatever template you started from, Jira represents the same five defaults underneath: Epic, Story, Task, Bug, and Subtask.

Story, Task, and Bug sit on the same level. None of the three is a parent to the other two, no matter how often teams treat Story as if it outranks Task in a sprint. Subtask always sits below whatever it's attached to, and Epic always sits above—that's the only fixed vertical relationship in the default scheme.

A one-line read on each, past the table:

Epic

An Epic works as a collector for the stories underneath it. Put simply, it's a container that holds everything working toward the same objective.

Use one when the goal is too big for a single sprint and will ship in pieces over weeks or months, such as a new billing system, a mobile app redesign, or moving off a legacy service. An Epic closes when the last issue inside it closes. If you're writing acceptance criteria for the Epic itself, what you have is a Story.

Story

A Story is typically written from the user's perspective — the classic user story format ("As a user, I want..."). It usually carries acceptance criteria that spell out the user need behind it and when the work is considered complete. If you can't finish that opening sentence, you probably need a Task instead.

Task

A Task covers development work with no user-facing angle attached to it — refactoring, configuration, a chore someone on the team just needs to get done. This could be anything from setting up a pipeline to cleaning up test data. If no user will ever notice the result and nothing is broken, file a Task.

➡️ More about issue types: Jira Epic vs Story vs Task.

Bug

A Bug marks a deviation from expected behavior, not a missing feature someone forgot to ask for. If the system is working as designed, it's a feature request, not a Bug. File a Bug when something worked and then stopped, or when the behavior contradicts the spec it shipped against. Put in the steps to reproduce and what you expected to see next to what actually happened. 

Subtask

A subtask is a slice of a parent issue that can't stand on its own. Remove the parent, and the subtask has nothing left to attach to. Subtasks work well for splitting one issue between people or stages, like design, backend and QA on the same Story. If a subtask would still make sense sitting in the backlog by itself, make it a Task or a Story.

Custom issue types: when you actually need one

A Custom Issue Type in Jira is a specialized work item created to address unique requirements or processes not covered by standard issue types. It is tailored to fit specific project needs, workflows, or industry standards, helping organizations better align Jira with their operational processes.

Before you add a sixth custom issue type, run the work through three questions.

• Does it need a different workflow? When a billing team asks for an Invoice type, because their process (Drafting → Sent → Past Due → Paid) doesn’t match a Task's To Do → In Progress → Done, that definitely earns a new type.
• Is the difference only in a value? Expense, labor, and licensing might look like three separate kinds of work, but they are just one kind with three possible values. To tell them apart, you just need to assign each one the appropriate label. Creating three custom issue types would mean maintaining three workflows and three field sets. That is a lot of overhead for something a custom field already handles.
• Can the work exist on its own? If the work can only ever show up as a consequence of something else, it belongs as a subtask, since a subtask inherits the parent's context by design.

A type earns its place only when it clears one of these on its own terms: a different workflow, fields nothing else needs, or reporting that has to isolate it from everything around it.

For example, in service management, custom Jira ticket types are particularly useful for handling specific service requests or incidents. Say, an "Access Request" custom issue type can be used to manage employee requests for system access, with workflows tailored to reviewing, approving, and granting access. Another example is a "Change Request," designed to manage proposed changes to IT infrastructure, standardizing the process and improving transparency.

What are parent and child issues?

Parent and child issues represent a hierarchical relationship in Jira.

• A parent issue is the item one hierarchy level above a child issue: an Epic is above a Story, a Story is above its subtask. 
• Parent and child describe a structural, one-way relationship, unlike the “blocks” or “relates to” links you set manually between issues at the same level. Next, we'll cover who can change that structure, and what happens when they get it wrong.

Btw, Planyway for Jira can show the same parent-child relationships as a browsable, table-like list — Epic → Story → Sub-task, or just Task → Sub-task if that's all your hierarchy needs — instead of opening each issue to check what's underneath it. You can also add levels above Epic, such as an Initiative or a Program.

Team-managed vs. company-managed in Jira Cloud

Jira Cloud offers two ways to structure a project, and the choice determines how much control a team has over its own configuration versus how consistent things stay across the organization.

In a company-managed setup, one scheme can serve fifty spaces, so a single edit reaches all of them at once. It works well when all teams share the same environment, but it becomes a problem when one team’s edge case ends up on every board by accident. 

Team-managed projects are self-contained — a space lead can add or edit issue types without waiting on anyone.

What you can undo in five minutes — and what you can't

Before you touch issue type configuration, it helps to know which changes are cheap mistakes and which ones you'll be living with. How well you understand what an issue type touches decides whether a mistake is free or permanent.

Easy to undo:

• Adding a subtask type
• Adding an Epic-level type above your existing hierarchy
• Adding a field

All three touch a narrow slice of your configuration and can be reversed easily.

Hard to undo: 

• Renaming an Epic — a site-wide action that lands at once on every dashboard, filter, or habit built around the old name.
• Inserting a hierarchy level between two existing ones — requires Advanced Roadmaps (Premium), and once other spaces start planning against it, pulling it back out is a big conversation.
• Deleting an issue type that already has data on it — forces Jira to migrate every one of those issues to a different type, which can break any field whose context was scoped to the type you just removed.

To prevent most of this, never edit the Default Issue Type Scheme directly: copy it first, then edit the copy.

Jira issue types best practices

Everything above comes down to five habits. While none of them are complicated on their own, the main challenge is to stick to these practices once a project has been running for a year and three people have each added "just one more" issue type along the way.

1. Design the issue type model first

• Define a clear issue type hierarchy. Start with the default structure: Epic → Story/Feature → Task/Bug → Subtask. Add custom issue types only when they represent a genuinely different kind of work. Too many custom types create confusion.
• Keep issue types purposeful and minimal. Every issue type should have a clear purpose. Document when to use each one.
• Use consistent naming conventions. Summaries should be specific, searchable, and action-oriented. For example: “Add SSO login for admin users” instead of “Login issue.”

2. Make each issue clear and actionable

• Write detailed descriptions and acceptance criteria. Include context, scope, dependencies, and definition of done. Stories should have acceptance criteria so everyone agrees on what “complete” means.
• Use labels and components consistently. Labels work well for cross-cutting tags; components work well for owned modules or areas. Apply them consistently so filters, boards, and reports stay reliable.

3. Design workflows around real work

• Customize workflows to match your team’s process. Use statuses such as To Do, In Progress, In Review, and Done. Make transitions logical and enforce required fields at key points.
• Link related issues. Use link types such as blocks, is blocked by, duplicates, and relates to. Link dependencies, duplicates, and related work so context is not lost.

4. Group and visualize work

• Use epics at a manageable size. If an epic becomes too large, split it. Use epic links to track related stories and tasks.
• Use Agile boards that match your workflow. Set up Kanban or Scrum boards that reflect how work actually flows. Use them to visualize work in progress and manage WIP.
• Use Agile-specific issue types only when they add clarity. Examples include Feature, Spike, Improvement, Incident, and Change Request. Add them only if they change how work is planned, tracked, or reported.

5. Maintain and improve over time

• Groom and maintain the backlog regularly. Prioritize, refine, estimate, and close or archive outdated issues.
• Use dashboards and reports. Track metrics such as burndown, velocity, cycle time, and throughput. Use them to improve the process, not to micromanage the team.

The bottom line

Whether you're running software development, a service desk, or plain project management, the hierarchy you land on needs someone who understands what each type controls, a written rule for when a new type earns its place, and a habit of checking whether the structure still matches how team members move work through it.

Every addition here (a subtask, an Epic, an Initiative) costs you almost nothing, while every removal or rename needs a negotiation with different teams, sometimes different groups across the whole instance. Start with the smallest structure that serves your business goals honestly, write the rule down, and hand it to different team members before the next person opens this admin panel without having read it.