Jira utilises a structured set of card types, formally known as Issue Types, to categorise and organise work. This hierarchy ensures that the correct level of detail and context is applied to every item, from the highest strategic goal down to the smallest coding change.
While the specific names and levels can be customized, the most common standard types fall into a three-to-four-tier structure, reflecting the planning horizons from portfolio to execution.
At the highest level are custom Issue Types like Initiative, Theme, or Program. These cards represent the largest strategic goals that often span quarters or years and require effort from multiple teams. Their purpose is to define whatthe organization is trying to achieve strategically. An Initiative, for example, might be "Launch the new customer portal." These cards live primarily in the top-level spaces or are managed using Advanced Roadmaps and serve as the Parent to many Epics, linking execution work directly back to strategic objectives.
The most common second-tier card is the Epic. An Epic is a large body of work that can be broken down into multiple, smaller stories. Its purpose is to describe a major feature or user value that can be delivered in several sprints. The Epic card provides the necessary context and narrative for the feature, such as "Implement the user login and registration flow." All work items at the execution level are linked to their respective Epic, serving as the bridge between the long-term plan and the short-term development effort.
This level represents the actual work being performed by the team in sprints.
Story (or User Story): This is the fundamental unit of delivery in Agile, describing a small feature from the perspective of the end-user (e.g., "As a user, I can reset my password"). Stories are estimated and planned into sprints.
Task: This represents a piece of work that needs to be done but isn't necessarily a user-facing feature (e.g., "Set up database schema").
Bug: This tracks a defect or error in the product that needs to be fixed.
These cards are all directly related to an Epic, and their completion ultimately defines the progress and completion of the parent Epic.
The lowest level is the Sub-task. A Sub-task is a checklist item used to break down a single Story or Task into even smaller, individual steps for team members (e.g., "Write unit tests for the login function"). Their purpose is to manage the highly granular steps of execution, and they do not live on the Backlog or require their own estimates, instead contributing to the estimate of their parent Story. This clear hierarchy ensures that every small unit of work contributes directly to a strategic goal, maintaining traceability and alignment across the entire organization.