What Is a Jira Ticket? How to Write One That Gets Done

A Jira ticket is a single, numbered piece of work tracked in Jira: a bug to fix, a story to build, a task to do. It has a key such as PAY-142, a title, a description, a type, a priority, a status and usually an assignee, and it moves across a board from To Do to Done. A ticket gets done when someone who has never seen it can read it once and know what “done” means. That comes down to a specific title, a description with the context and the acceptance criteria, and one owner.

Jira ticket, Jira issue, work item: the same thing

People say “ticket” and “issue” interchangeably, and both still work in search, in conversation and in the API. Jira Cloud itself has changed the words. Atlassian’s own guide to Jira work items↗ (opens in a new tab) now says teams use work items, “formerly known as issues”, and its help pages call issue types “work types” and projects “spaces”. As of October 1, 2026, that is the vocabulary you will see on screen in Jira Cloud. This post says “ticket” because that is what most people type, and it means exactly what Jira now calls a work item.

The name “Jira ticketing system” comes from the same idea: every request becomes a ticket with its own key, history and status, so nothing is tracked in somebody’s inbox.

The anatomy of a Jira ticket

Which fields appear depends on how your admin set up the space, but almost every Jira ticket has these:

• Title. One line that says what is wrong or what is wanted. Atlassian’s help on creating a work item↗ (opens in a new tab) says this field was previously labeled Summary, and that JQL, API calls and automations that reference summary still work.
• Description. The context: what happens now, what should happen, how to reproduce it, and how you will know it is finished.
• Type. Bug, story, task, epic or subtask in a software space. It decides which fields and which workflow the ticket gets.
• Priority. By default Highest, High, Medium, Low and Lowest, which admins can rename and redefine.
• Assignee. The one person who owns the next step. Unassigned tickets tend to stay unassigned.
• Status. Where the ticket is in its workflow. A simple board uses To Do, In Progress and Done; many teams add In Review.
• Labels. Free-text tags for filtering, such as checkout or ios. Useful when a team agrees on a short list; noise when everyone invents their own.
• Components. Groups of tickets by product area or team, with optional owners and auto-assignment. According to Atlassian’s page on components↗ (opens in a new tab), they exist only in company-managed spaces.
• Sprint. Which sprint the ticket is planned into, on a Scrum board. A subtask inherits its parent’s sprint.

Atlassian’s page on statuses, priorities and resolutions↗ (opens in a new tab) lists the default priorities and statuses and explains that admins can change both, which is why two Jira sites rarely look the same.

Jira issue types, in one line each

These are the defaults Atlassian lists for a software space on its work types page↗ (opens in a new tab):

• Epic: a big user story that needs to be broken down into smaller pieces.
• Story: the smallest unit of work that needs to be done, usually written from the user’s point of view.
• Task: work that needs doing and is not a bug or a story.
• Bug: a problem that stops the product from working as it should.
• Subtask: one step of a larger ticket, tracked on its own.

If you are unsure which to pick, the honest test is what the reader needs: reproduction steps (bug), a user and a reason (story), or just an instruction (task). For writing the story kind well, see the user story template.

How to write a Jira ticket that gets done

1. Put the where and the what in the title. “Checkout: ZIP+4 codes rejected at the shipping step” beats “Checkout broken”. Someone scanning a board of fifty tickets should know which one this is.
2. Start the description with the current behavior, then the expected behavior. One sentence each.
3. For a bug, give steps to reproduce, the browser or device, and the exact error. The bug report template has the full list.
4. Write acceptance criteria as checks someone else can run. “Works for all ZIP formats” is a hope; “ZIP 94105 and ZIP+4 94105-1804 both pass, 9410 fails with a message” is a test.
5. Say what is out of scope. It stops the ticket from quietly growing.
6. Link what exists: the error log, the screenshot, the related ticket, the commit. Do not paste a long log into the description.
7. Give it one assignee and a priority you would defend. If everything is High, nothing is.
8. Keep it small enough to finish in a few days. If it is bigger, make it an epic and split it.

A worked example

Here is a bug ticket written that way. Paste it into the description of a new work item and change the details.

Title: Checkout: ZIP+4 codes rejected at the shipping step
Type: Bug    Priority: High    Assignee: Dana Lee
Labels: checkout    Component: Web storefront

Current behavior
Entering a ZIP+4 code (94105-1804) in the shipping address
shows "Enter a valid ZIP code" and blocks the order.

Expected behavior
ZIP+4 codes are accepted, the same as 5-digit ZIP codes.

Steps to reproduce
1. Add any item to the cart and go to checkout.
2. Enter a US shipping address with ZIP 94105-1804.
3. Select Continue. The error appears.
Seen in Chrome on macOS and Safari on iPhone.

Acceptance criteria
- 94105 and 94105-1804 are both accepted.
- 9410 and 94105-18 show "Enter a valid ZIP code".
- Sales tax is calculated from the first five digits.

Out of scope
Canadian postal codes (separate ticket, PAY-150).

Notice what is not there: no opinions about the cause, no “ASAP”, no paragraph of background. The assignee can start in a minute, and the reviewer knows exactly what to check before moving it to Done.

Habits that keep a Jira board readable

• Search before you file. A duplicate ticket splits the conversation in two.
• Comment, do not edit history away. If the plan changes, say so in a comment so the next reader knows why.
• Close tickets with a reason: fixed in which commit, or won’t fix and why.
• Review the board, not the inbox. Our Jira kanban best practices cover columns, limits and the weekly review.

Letting an AI assistant write and update Jira tickets

An assistant connected to Jira over MCP can file tickets in this format and move them as it works. Pick the guide for your setup and do not repeat the work here:

• Jira MCP with Claude Code: setup, prompts and limits in the terminal.
• Jira MCP in Cursor: the mcp.json entry, sign-in and approvals.
• Jira MCP with GitHub Copilot: the VS Code setup.
• Jira MCP for Data Center: options when Jira is self-hosted.
• Jira MCP vs the Jira API: which one your assistant should use.

A simpler alternative to Jira tickets

Jira is built to be configured: work types, workflows, fields, screens and schemes. A team of three building one product often spends more time choosing fields than writing tickets. If that is you, a board with fewer choices can carry the same good ticket.

In fenbs a ticket is a task with a ref such as BUG-014 that is never reused, one of three kinds (feature, enhancement, bug), a priority from 1 to 10 where 1 is the most urgent, and one of four lanes: To Do, Next Up, In Progress, 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. The history records who changed what, and AI assistants such as Claude or Cursor connect over MCP as members of the board, under a role.

Be clear about what you give up. fenbs has no sprints, no due dates, no epics, no subtasks, no custom fields and no settable assignee. If your process depends on those, stay with Jira. The full side-by-side is on fenbs vs Jira.