JIRA Issues
An issue in JIRA represents a single unit of work. Every task, bug, feature request, or improvement that a team tracks in JIRA exists as an issue. Issues are the foundation of JIRA — projects hold them, boards display them, sprints organize them, and reports measure them. Understanding how to create, manage, and link issues effectively makes JIRA genuinely useful for any team.
What Is a JIRA Issue?
A JIRA issue is a digital record that captures everything about a piece of work. It holds a title, a description, a status, an assignee, a priority, and a history of all changes. Every issue gets a unique ID like MBA-42 that the entire team uses to reference that work item.
Real-World Analogy: An issue works like a physical job card in a factory. The card describes what needs to be built, who builds it, and what stage it is in. Workers pick up cards, complete the work, and move the card to "Done." JIRA issues do the same thing — digitally and for any type of work.
Anatomy of a JIRA Issue
Every JIRA issue contains a standard set of fields. Some fields are mandatory, and some are optional. Here is a full breakdown of all common issue fields.
| Field | Type | Purpose | Example Value |
|---|---|---|---|
| Issue ID | Auto-generated | Unique identifier for this issue | MBA-42 |
| Issue Type | Dropdown | Classifies the nature of the issue | Story |
| Summary | Short text | One-line title describing the task | Build OTP verification screen |
| Description | Rich text | Full details, context, or acceptance criteria | User must enter a 6-digit OTP sent to their phone... |
| Status | Workflow state | Shows current stage of the issue | In Progress |
| Priority | Dropdown | Indicates urgency level | High |
| Assignee | User picker | Person responsible for completing the issue | Rahul Mehta |
| Reporter | User picker | Person who created the issue | Priya Sharma |
| Epic Link | Issue link | Parent epic this issue belongs to | MBA-10 (User Authentication) |
| Sprint | Sprint picker | Sprint where this issue is assigned | Sprint 3 |
| Story Points | Number | Effort estimate for the issue | 5 |
| Labels | Free-text tags | Keywords for filtering and grouping | authentication, mobile, security |
| Components | Dropdown | Sub-area of the project this issue belongs to | Login Module |
| Fix Version | Version picker | The software version that will include this fix | v2.1.0 |
| Due Date | Date picker | Deadline for completing this issue | 2024-08-15 |
| Original Estimate | Time (e.g., 4h) | Initial time estimate before work starts | 8h |
| Time Spent | Logged via worklog | Actual time recorded during work | 6h 30m |
| Attachments | File uploads | Screenshots, documents, or design files | wireframe-login.png |
Issue Priority Levels
Priority tells the team how urgently an issue needs attention. JIRA comes with five default priority levels. Teams can customize these levels to match their processes.
| Priority | Icon Color | Meaning | When to Use |
|---|---|---|---|
| Highest | Dark Red | Critical — production is down or broken | System crash, data loss, security breach |
| High | Red | Significant impact on many users | Login failure, payment error |
| Medium | Orange | Some impact but a workaround exists | UI glitch, slow performance |
| Low | Blue | Minor inconvenience | Typo in a tooltip, minor color mismatch |
| Lowest | Light Blue | Nice-to-have with no urgency | Feature suggestion, cosmetic improvement |
The Issue Status and Workflow
Every issue moves through a series of statuses from creation to completion. These statuses form the workflow. The default workflow for most JIRA projects looks like this:
| Step | Status | Meaning | Who Acts |
|---|---|---|---|
| 1 | To Do | Issue created but work not started | PM or Developer |
| 2 | In Progress | Developer actively working on it | Developer |
| 3 | In Review | Code written, awaiting peer review or testing | Reviewer / QA |
| 4 | Done | Work complete and verified | Developer or QA |
The transition between statuses happens by clicking the status button on the issue detail view and selecting the next status from the dropdown.
Linking Issues Together
Issues often relate to each other. JIRA provides a linking feature to capture these relationships. Linked issues appear in a "Linked Issues" section on the issue detail view.
| Link Type | Meaning | Example |
|---|---|---|
| blocks / is blocked by | One issue stops another from progressing | MBA-30 blocks MBA-42 (API must be ready before screen) |
| duplicates / is duplicated by | Two issues describe the same problem | MBA-55 duplicates MBA-42 |
| relates to | Issues are related but not dependent | MBA-42 relates to MBA-18 |
| clones / is cloned by | One issue is a copy of another | MBA-60 clones MBA-42 (same task in another sprint) |
Sub-tasks: Breaking Work into Smaller Pieces
A sub-task is a child issue that lives inside a parent issue. Use sub-tasks when a single issue contains multiple distinct steps that different people complete. Sub-tasks appear under the parent issue in the "Child Issues" section.
| Level | Issue | Assignee |
|---|---|---|
| Parent Story | MBA-42: Build OTP verification screen | Rahul Mehta |
| Sub-task 1 | MBA-43: Design OTP input UI component | Anjali Singh (Designer) |
| Sub-task 2 | MBA-44: Implement OTP API integration | Rahul Mehta (Developer) |
| Sub-task 3 | MBA-45: Write unit tests for OTP flow | Deepak Patel (QA) |
How to Log Work on an Issue
Work logging records how much time a team member spent on an issue. This data feeds into JIRA reports and helps track actual vs estimated effort. Access the work log from the issue detail view under the "Log Work" button.
Work Log Fields
| Field | What to Enter |
|---|---|
| Time Spent | Duration of work (e.g., 2h 30m) |
| Date Started | The date the work was performed |
| Remaining Estimate | How much time is still needed to finish |
| Work Description | Optional notes about what was done |
Commenting on Issues
The comment section at the bottom of every issue allows team members to discuss the work, ask questions, and share updates. Comments support rich text formatting, file attachments, and @mentions to notify specific users.
Best Practice: Always use @mentions in comments instead of sending a separate email. When a user is @mentioned, they get a JIRA notification. This keeps all communication inside the issue and creates a searchable history of decisions.
Watching an Issue
Clicking the "Watch" icon on any issue adds it to the watchers list. Watchers receive JIRA notifications whenever the issue is updated, commented on, or its status changes. This is useful for staying informed about issues that are not directly assigned but still matter to the viewer.
Cloning an Issue
Cloning creates an exact copy of an existing issue including all its fields. The clone appears as a new issue with its own unique ID. Teams use cloning to repeat similar work across sprints without rewriting the same description every time.
Summary
JIRA issues are the core data unit that makes project tracking possible. Each issue captures work details, ownership, status, and history in one place. Priorities guide urgency. Statuses reflect progress. Links and sub-tasks show relationships. Work logs track effort. Comments capture decisions. Together, these features turn a simple task list into a complete, traceable record of team work. The next step is to understand the different types of issues that JIRA supports and when to use each one.