Jira Issue Types: Epic, Story, Task, Bug and Subtask

Jira issue types are the categories every piece of work in Jira belongs to. In Jira Cloud they are now called work types, and issues are now called work items, though the old names still work in search and conversation. A software space comes with five: epic for a large body of work, story for a change a user would notice, task for work that is neither, bug for something broken, and subtask for one step of a larger item. They form three levels, epic on top, story, task and bug in the middle, and subtask underneath. Add a custom type only when it needs different fields or a different workflow, not just a different name.

Issue types are now work types

Atlassian renamed the vocabulary across Jira Cloud. Its help page What are work types?↗ (opens in a new tab) says “Work types distinguish different categories of work” and that they help teams search, sort, track progress and estimate how they respond to each category. The page addresses still say issue-types, JQL still accepts issuetype, and most people still type “issue types” into a search box. As of October 1, 2026, the screens say work type, work item and space. This post uses both, because you will meet both.

The five default issue types in Jira

A software space starts with these five. The quoted descriptions are Atlassian’s own; the rest is how teams use them in practice.

• Epic: “A big user story that needs to be broken down.” An epic groups the stories, tasks and bugs that deliver one outcome, such as a new checkout. It is finished when its children are, and Jira uses it to drive the timeline and some reports.
• Story: “The smallest unit of work that needs to be done.” Usually written from the user’s side: who wants what, and why. A story should be small enough to finish in days, not weeks.
• Task: “Work that needs to be done.” The catch-all for work that is not a user-facing change and not a defect, such as renewing a certificate or setting up a staging database.
• Bug: “A problem which impairs or prevents the functions of a product.” A bug needs steps to reproduce, the expected result and the actual one. Jira bug tracking covers the workflow and fields that keep bugs from piling up.
• Subtask: “A piece of work required to complete a task.” Subtasks split a story, task or bug into steps that different people can pick up. They always belong to a parent item and cannot stand alone.

Business spaces start with only task and subtask, and Jira Service Management spaces come with their own set, including incident, problem, change and service request. If you are unsure whether something is a story or a task, user story vs task has four questions that settle it, and what is a Jira ticket shows how to write any of them so it gets picked up.

The Jira issue type hierarchy

Work types sit at levels, and the level decides what can be a parent of what. Atlassian’s page on configuring the work type hierarchy↗ (opens in a new tab) lists three default levels: level 1 for epics, level 0 for standard work items such as stories, tasks and bugs, and level -1 for subtasks. An item can only be the child of something one level up.

Level 1   EPIC     STORE-200  Checkout: accept Apple Pay
Level 0     STORY    STORE-201  As a returning customer, I can pay with Apple Pay on iPhone
Level -1      SUB    STORE-205  Add the Apple Pay button to the payment step
Level -1      SUB    STORE-206  Verify the merchant domain with the payment provider
Level -1      SUB    STORE-207  Test on Safari for iOS and macOS
Level 0     STORY    STORE-202  As a guest, I can pay with Apple Pay without an account
Level 0     TASK     STORE-203  Update the privacy policy to name the new payment method
Level 0     BUG      STORE-204  Sales tax shows as zero when the Apple Pay sheet is canceled

Two rules from that page are worth knowing before anyone touches the hierarchy. First, adding levels above epic, often called initiative or theme, is limited to Jira Premium and Enterprise, and only applies to company-managed spaces. Second, changing the hierarchy can break existing parent and child links, and Atlassian says those changes cannot be undone. Plan it on paper first.

When to add a custom issue type

Custom work types are easy to create and hard to retire, because every one of them needs fields, a workflow and a place in every filter and report. A good test is whether the new type changes how the work is handled, not only what it is called.

• Add one when the work needs different fields. A “Security finding” that must record a severity score, the affected component and a disclosure date is a fair candidate.
• Add one when it follows a different workflow. A “Content request” that goes Draft, Legal review, Approved, Published does not fit a bug’s statuses.
• Add one when you must report on it separately and a label or component will not do.
• Do not add one for a team name, a customer name or a priority. Those are fields, components or labels.
• Do not create your own type called “Epic” or a homemade parent type. Atlassian’s team-managed help says to use the suggested Epic type, because Jira uses it to power the timeline and reports.

How to add one

In a team-managed space, a space admin opens the space settings, chooses Work types and selects Add work type. Atlassian’s guide to setting up work types in team-managed spaces↗ (opens in a new tab) says you can add up to 30, and each one can show its own fields, with any of them marked required.

In a company-managed space, it takes a Jira admin with the Administer Jira permission. Atlassian’s page on adding, editing and deleting a work type↗ (opens in a new tab) walks through Settings, Work items, Work types, then Add work type, where you choose a standard or subtask type and attach it to a work type scheme so spaces can use it. Before deleting a type, search for the items that use it and move them to another type in bulk.

Proposed work type:   Security finding
Level:                standard (level 0)
Why not a label?      needs its own required fields and workflow
Required fields:      severity (Critical/High/Medium/Low), component, found by
Workflow:             Reported -> Confirmed -> Fixing -> Verified -> Disclosed
Who files it:         QA, the security contractor, the on-call engineer
Reports that need it: open findings by severity, monthly
Owner of the scheme:  Dana Lee (Jira admin)
Review date:          January 15, 2027 -- delete it if fewer than 5 items exist

The flat model: one level, three kinds

Many small teams never use most of this. They make an epic, forget it, and the subtasks end up holding the real work. If that sounds familiar, the opposite design is worth a look: one level of work, and a small fixed set of kinds that says what each item is.

• Every item is a feature (something new), an enhancement (a change to something that exists) or a bug (something that does not work as intended).
• There are no parents and children. A large piece of work is split into items that each make sense alone, with the shared word in the title.
• Order comes from priority and lane, not from nesting.
• Steps inside one item go in its plan, as text, rather than as subtasks.

That is how fenbs works. Every task is one of three kinds, with a ref such as FET-031, ENH-032 or BUG-033, a priority from 1 to 10 where 1 is the most urgent, and one of four lanes: To Do, Next Up, In Progress and Completed. The note holds the problem, the plan holds how it will be done, and a test status with test notes says how it was checked. Add many takes a pasted list and makes each line a task, with a prefix setting the kind:

feature: Checkout: Apple Pay for returning customers on iPhone
feature: Checkout: Apple Pay for guests without an account
enhancement: Checkout: name Apple Pay in the privacy policy
bug: Checkout: sales tax shows as zero when the Apple Pay sheet is canceled

Be clear about what you give up. fenbs has no epics, no subtasks, no custom work types, no sprints, no due dates and no settable assignee. If your reporting depends on epics rolling up, or a regulator wants a custom workflow per type, stay with Jira. If your team mostly wants to know what is next and what is broken, three kinds on one level is often enough. The full side-by-side is on fenbs vs Jira.