Jira issue types
A Jira issue is the atomic unit of work inside Jira — one task, one bug, one request — and the issue *type* is how you label what kind of work it is. Get the types right and the rest of Jira starts to behave: reports make sense, hierarchies hold together, and teams stop arguing about whether a thing is a story or a task.
This is a working guide to the standard issue types, how parent/child relationships and Jira's hierarchy fit together, what an issue actually contains, and where custom types earn their keep.
What is an issue in Jira?
An issue in Jira represents a single task or activity a developer or team needs to complete — a project assignment, a helpdesk ticket, a request form. Each issue captures the information that makes work trackable: assignee, description, status, affected systems. That data pays off in three places:
Transparency: Teams that track issues consistently develop a shared picture of the work they take on, which improves communication and hand-offs.
Prioritization: Ranking issue types helps teams surface critical work and improve both throughput and quality.
Reporting: Project managers use issues as concrete evidence of progress for stakeholders — showing what kind of work the team does, how often, and where the trends point.
Jira issue types
Jira ships with a handful of standard issue types that cover most work. These are the ones you'll see across almost every project:
Epics: A collection of related issues grouped under a shared objective. Epics can contain stories, tasks, or bugs.
Stories: Used in agile development to describe a feature from the user's point of view.
Tasks: A catch-all for work that doesn't fit neatly into another type.
Bugs: A defect or error that needs fixing.
Subtasks: Smaller units of work broken out of a larger issue, sometimes called child issues.
Custom issue types
Administrators can extend the default list with custom types tailored to how a team works. The available types also depend on the Jira product in use — Software, Service Management, or Work Management. Common custom types include:
Change
IT help
Incident
New feature
Problem
Service request
Support
Improvement
Test case
Spike
Technical debt
Research
Parent and child issue relationships
Jira uses "parent" and "child" to describe dependencies between issues.
Parent: An issue that contains subtasks. Delivery of the parent depends on the children being completed.
Children: The subtasks that roll up to a parent issue.
If the parent task is to build a new website, the children might include:
Wireframe development
Graphic design
Backend programming
Copywriting
Each child has to close for the parent to close.
The parent/child pattern isn't limited to standard types — any issue can have a child, including bugs with sub-bugs. The one exception is subtasks: they can't become parents, since nothing sits below them in the hierarchy.
Understanding Jira issue hierarchy
The parent/child link is one way issues relate; Jira's built-in hierarchy is another. The hierarchy defines where each piece of work sits in the overall scope of a project.
Jira's native hierarchy has three levels, from top to bottom:
1. Epics: Broad objectives that require completing many tasks, stories, or bugs. 1. Issues: Stories and tasks that support the epic. Bugs live here too — errors that need to be fixed before the epic can ship. 1. Subtasks: The smallest units of work, which make up stories, tasks, and bugs.
Anatomy of a Jira issue
A Jira issue can hold a lot of information, including:
Assignee
Due date
Status
Category
Priority
Jira stores this data in individual issue fields. Some are standard; others are custom fields created by an administrator. Every field feeds reporting and tracking downstream.
Choosing the right fields matters more than most teams realize: When the information a team needs is present on the issue, work flows in the right order and productivity climbs. When it isn't, people ask the same questions again in Slack.
Once you've decided what information to capture, the issue layout is straightforward to configure. Atlassian splits the Jira issue page into five standard regions that admins can arrange from the browser.
The standard regions on a Jira issue page are:
1. Description
The first place developers look for information. Best practice is to put the most important context here.
2. Field tabs
Located at the top of the issue view. Admins use them to organize data relevant to different groups on the project team.
3. Context fields
When an admin creates a custom field, Jira assigns it a context field that can be pinned above the "Details" box. Context lets the admin set default language and value and scope the field to specific issue types or projects.
4. More fields
The "More fields" area sits below the "Details" panel and holds supporting information that doesn't drive workflow. Empty fields here are hidden from view.
5. Configure issue layout
The "Configure" button lets admins rearrange the page and toggle field visibility, so the most important information stays in front of the people doing the work.
Managing Jira issue types with Tempo
Tempo offers a set of applications for teams that need more from Jira issues than Jira ships with out of the box. Gantt Charts for Structure PPM uses real-time automation to keep project plans and roadmap visualizations aligned as issues change.
Timesheets brings time tracking and capacity management directly into Jira, logging and reporting on issue data with a few clicks and surfacing productivity through burn-up charts and time-per-issue reports.
Timesheets pairs with Financial Manager, which monitors projects, epics, and portfolios to give real-time visibility into cost, budget, and profit — and to make trends visible across the organization.
