JIRA Issue Types
JIRA uses different issue types to classify the nature of work. Each issue type serves a distinct purpose. Choosing the correct type helps teams organize their backlog, measure velocity accurately, and generate meaningful reports. Using the wrong type — like logging every piece of work as a Task — creates confusion and makes reporting less accurate.
The Standard JIRA Issue Type Hierarchy
JIRA issue types follow a parent-child hierarchy. An Epic contains Stories, Tasks, and Bugs. Stories and Tasks contain Sub-tasks. This hierarchy connects all levels of work from a high-level business goal down to a single day's work.
| Level | Issue Type | Scope | Example |
|---|---|---|---|
| Level 1 (Largest) | Epic | Large feature or business goal spanning multiple sprints | User Authentication Module |
| Level 2 | Story | User-facing feature that fits within one sprint | As a user, I want to log in using my email and password |
| Level 2 | Task | A technical or non-development activity | Set up staging environment for authentication API |
| Level 2 | Bug | A defect or unexpected behavior in existing functionality | Login button not responding on Android 13 |
| Level 3 (Smallest) | Sub-task | A specific step within a Story, Task, or Bug | Design login screen wireframe |
Epic
An Epic represents a large body of work that the team cannot complete in a single sprint. It acts as an umbrella that groups related Stories, Tasks, and Bugs together under one business goal. Epics appear in the Roadmap view and span across multiple sprints on the backlog.
When to Create an Epic
- A feature is too large to complete in one 2-week sprint
- Multiple stories share a common business objective
- Stakeholders need a high-level view of progress on a major initiative
Epic Example
| Epic | Child Issue | Type |
|---|---|---|
| Checkout Flow | Build shopping cart screen | Story |
| Add payment method selection | Story | |
| Integrate payment gateway API | Task | |
| Fix double-charge bug on retry | Bug |
Epic-Specific Fields
| Field | Purpose |
|---|---|
| Epic Name | Short label used on the board and roadmap (different from Summary) |
| Epic Color | Visual color tag to identify the Epic on the board at a glance |
| Start Date | When work on the Epic is expected to begin |
| Due Date | Target completion date for the entire Epic |
Story (User Story)
A Story describes a feature from the perspective of the end user. It focuses on what the user wants to do and why, not how the developer builds it. Stories follow a standard writing format called the "3C" format: Card (short title), Conversation (description), and Confirmation (acceptance criteria).
Standard Story Format
As a [type of user], I want to [action], so that [benefit].
Story Examples
| Poor Story | Good Story |
|---|---|
| Build login page | As a registered user, I want to log in with my email and password so that I can access my account dashboard |
| Fix notification | As a mobile user, I want to receive push notifications for order updates so that I know when my package is dispatched |
| Add search | As a shopper, I want to search products by name so that I find what I need without browsing all categories |
Acceptance Criteria
Acceptance criteria define exactly when a story is considered complete. They live in the Description field of the story. Clear acceptance criteria prevent disagreements between developers and QA about what "done" means.
| # | Acceptance Criterion |
|---|---|
| AC1 | User enters a valid email and password and clicks Login — system redirects to dashboard |
| AC2 | User enters wrong password — system shows "Invalid credentials" message without page reload |
| AC3 | User leaves email empty — system shows "Email is required" validation message |
| AC4 | Login page loads in under 2 seconds on a 4G connection |
| AC5 | Login form meets WCAG 2.1 accessibility standards |
Task
A Task represents a piece of work that is not a user-facing feature. Tasks cover technical work, infrastructure changes, research, documentation, or any activity that supports the project but does not directly deliver functionality to the user.
When to Use a Task Instead of a Story
| Situation | Correct Type | Reason |
|---|---|---|
| Build a new feature visible to users | Story | Delivers user value — follows user story format |
| Set up CI/CD pipeline | Task | Technical infrastructure — no direct user benefit |
| Write API documentation | Task | Internal deliverable — not a user-facing feature |
| Upgrade database version | Task | Maintenance work — users do not see it |
| Add a product filter for customers | Story | Customer-facing feature — fits "As a user..." format |
Bug
A Bug represents an error, defect, or unexpected behavior in existing functionality. Bugs arise when something that previously worked correctly stops working, or when a feature behaves differently from its specification. QA testers, product managers, and end users all report bugs.
How to Write a Good Bug Report in JIRA
| Field | What to Write | Example |
|---|---|---|
| Summary | [Where] + [What breaks] + [When] | Login button not responding on Android 13 after entering valid credentials |
| Steps to Reproduce | Numbered steps anyone can follow to see the bug | 1. Open app on Android 13. 2. Enter valid email/password. 3. Tap Login. 4. Nothing happens. |
| Expected Result | What should happen | User redirects to dashboard within 2 seconds |
| Actual Result | What actually happens | Button tap registers visually but no navigation occurs |
| Environment | Device, OS, browser, app version | Android 13, Samsung Galaxy S23, App v2.1.3 |
| Severity / Priority | Impact level | High — affects all Android 13 users |
| Attachment | Screenshot or screen recording | login-bug-recording.mp4 |
Sub-task
A Sub-task is the smallest unit in the JIRA hierarchy. It lives inside a parent issue (Story, Task, or Bug) and represents one specific action needed to complete the parent. Sub-tasks are useful when a story requires work from multiple people with different skills.
Sub-task Example
| Parent | Sub-task | Assignee | Estimated Hours |
|---|---|---|---|
| MBA-42: Build OTP verification screen | Create UI wireframe for OTP screen | Anjali (Designer) | 4h |
| Develop front-end OTP input component | Rahul (Developer) | 8h | |
| Connect OTP API and handle responses | Vikram (Developer) | 6h | |
| Test OTP flow on all target devices | Deepak (QA) | 4h |
Additional Issue Types
Some JIRA configurations include additional issue types depending on the team's process.
| Issue Type | Purpose | Common In |
|---|---|---|
| Improvement | Enhancement to existing functionality (not a bug) | Software teams |
| New Feature | Brand new functionality not previously available | Software teams |
| Spike | Research or investigation task with a time-boxed limit | Agile teams |
| Change Request | Formal request to change an existing specification | Service Management |
| Incident | Unplanned interruption to service that needs resolution | IT operations teams |
| Problem | Root cause of one or more incidents | IT operations teams |
| Service Request | A formal request for service from a customer or employee | Service Management |
Customizing Issue Types
JIRA Administrators can add, rename, or remove issue types at the global or project level. Custom issue types are useful when the default types do not match the team's terminology or process. For example, a legal team might create an issue type called "Contract Review" instead of using "Task."
Choosing the Right Issue Type — Quick Reference
| Question | Answer | Use This Type |
|---|---|---|
| Is it a large initiative spanning many sprints? | Yes | Epic |
| Does it deliver direct value to an end user? | Yes | Story |
| Is it technical work with no direct user impact? | Yes | Task |
| Is something broken that used to work? | Yes | Bug |
| Is it a small piece of a larger issue? | Yes | Sub-task |
| Is it research or investigation work? | Yes | Spike (or Task) |
Summary
JIRA issue types create a clear structure for different kinds of work. Epics group large goals. Stories capture user-facing features. Tasks cover technical and non-feature work. Bugs document defects. Sub-tasks break down complex work into assignable steps. Using the correct issue type for each piece of work keeps the backlog clean, reporting accurate, and sprint planning straightforward. Understanding workflows — how issues move from one status to the next — is the next key concept to master.