What Makes a Good Jira Ticket? Examples and Anti-Patterns

A good Jira ticket states what changes in its title, gives enough context for someone who missed the conversation to start work, defines done in checkable terms, and holds one piece of work rather than five. Everything else is optional. Most bad tickets fail on the first and third of those, not on formatting.

This is for product managers, tech leads and engineers whose board is full of items nobody can interpret without asking. It covers the fields that carry real information, the title, a weak ticket rewritten, what a bug report needs, the anti-patterns, and how much detail is warranted.

What makes a good Jira ticket?

A good ticket puts a decision in every field it fills in. Jira gives you plenty of fields and most teams treat them as a form. Treat them as questions instead, and these are the ones worth answering.

• Summary. The one field that appears in every view. It gets its own section below because it is the field most often wasted.
• Issue type. Less a taxonomy than a switch. Type drives which workflow the item follows, where it sits in the hierarchy and how it appears in reports. Pick the type that gets the work onto the right board, not the one that satisfies a definition.
• Description. Three things belong here: why this exists, what changes, and what finished looks like.
• Assignee. One person. A field with a name in it is a commitment; a field with a team in it is a hope.
• Parent or epic link. Where this sits in the larger piece of work. Without it, the epic is a label rather than a plan.
• Priority. Only meaningful if the levels behave differently. If every ticket is High, take the field off your screen and stop pretending.
• Issue links. Blocks, is blocked by, relates to. Teams skip this one, and it is the field that explains why a sprint stalled.
• Labels and attachments. Add a label only if somebody filters on it. Attach the log line or request ID rather than describing it, because a ticket that describes its evidence makes the assignee go and find it.

Which fields exist, which are mandatory and which appear on which screen varies, because Jira screens and workflows are configured per project rather than globally. Atlassian’s documentation now calls these items work items rather than issues, though almost nobody has changed what they say out loud.

What goes inside the description, and how a ticket differs from a user story or a use case, is covered in user stories, use cases and tickets. This article is about the container.

How do you write a ticket title someone will recognise six weeks later?

Write the title so it names what changes, specifically enough to be identified in a list of forty without opening it. That is the whole test. The title is read hundreds of times and written once, usually in about four seconds, and everyone who scrolls the board pays for that asymmetry.

Two habits produce most bad titles. The first names the area rather than the change: “Login”, “Payments”, “Dashboard”. The second names the verb without the object: “Fix bug”, “Investigate”, “Update”. Both read fine to the author on the day, because the author is holding the context the title is supposed to carry.

Weak title	Stronger title
Fix login	Show a lockout message instead of a 500 when the account is locked
Payments bug	Duplicate refund created when the provider times out and the agent retries
Update API	Add pagination to GET /orders with a default page size of 50
Dashboard improvements	Show the last sync time in the dashboard header
Tech debt	Remove the second copy of the address validator in checkout

Three rules. Lead with a verb where the ticket is a change and with the symptom where it is a bug. Keep it short enough to survive being clipped in a board or list view, which usually means well under seventy characters. And never lean on the ticket key for meaning, because “PROJ-4471” tells a reader nothing and half the people discussing the work are reading it in Slack, not in Jira.

What does a good Jira ticket look like?

Here is one piece of work written twice, first the way it usually arrives.

Summary: Export broken

Description: Customer says the CSV export is wrong. Can we look at this please.

Nobody can start that. It does not say which export, which customer, what wrong means, or what would count as fixed. The assignee’s first action is to find the author, and if the author is on leave the ticket waits.

Now the version that can be picked up:

Summary: Orders CSV export omits refunded lines when a date filter is applied

Description: Reported by two enterprise accounts this week (support threads linked). The Orders export includes refunded lines when run unfiltered and drops them when any date range is applied. Finance reconciles from this file, so its totals no longer match the dashboard.

Scope: the Orders export only. The Payouts export has a separate filter path and is not part of this ticket.

Done when: a date-filtered export contains every order created in the range, including refunded and partially refunded ones, and the row count matches the Orders list view for the same filter.

Notes: reproduces on the sandbox account with any range longer than one day. Feature flag orders_export_v2 is on for that account.

Open question: whether cancelled orders should appear at all. Asked Priya in #finance-ops, answer expected Thursday. Not blocking the fix.

The rewrite is longer because six questions were answered in advance rather than asked one at a time over three days. The scope line and the open question are the two parts most often missing, and the two that decide whether anyone other than the author can pick it up. For the criteria themselves, acceptance criteria formats and how they differ from definition of ready covers the options.

What does a bug ticket need that a feature ticket does not?

A bug ticket needs reproduction steps, and without them it is a request for someone else to do the diagnosis you skipped. A feature ticket describes work that has not happened. A bug ticket describes an event that already has, and the person who saw it holds evidence nobody else can recover.

Six things, in this order:

1. Steps to reproduce, numbered, starting from a known state. “Log in as a support agent, open order 10432, apply a date filter of 1 to 31 July, click Export.” Not “try exporting”.
2. What happened. The observed behaviour, quoted exactly if it is an error message. Paraphrased errors send people hunting for strings that do not exist.
3. What you expected. Often obvious, occasionally not, and where it is not obvious this line prevents a fix that satisfies nobody.
4. Environment and build. Which environment, which version or commit, which browser or client, which account and role. Bugs that only reproduce under one permission are common and invisible without this.
5. Frequency and scope. Every time or once. One customer or all of them. Since a specific deploy or always. This is what turns a bug into a priority, or fails to.
6. Evidence. Request ID, trace, log excerpt, screenshot, the exact timestamp with a timezone.

If it does not reproduce reliably, say so and say what you tried. An intermittent bug written up honestly is useful. The same bug written up as though it were deterministic wastes an afternoon and comes back as “cannot reproduce, closing”.

Whether severity is recorded separately from priority depends on your configuration. Where both exist, keep the distinction honest: severity is how badly it behaves, priority is when somebody will do something about it.

Jira ticket anti-patterns, and what each one costs

Each of these costs something specific rather than being generally untidy.

1. The note to self. One line in the author’s private shorthand. Cost: the work cannot be reassigned. It is a personal to-do stored in a shared system, and when that person is busy or gone it becomes dead weight that still shows on the board.
2. The five-in-one. Several unrelated changes in one ticket because they came up in the same meeting. Cost: it can never be finished, only partly finished. Progress is unreportable, the review is enormous, and one blocked piece holds the other four hostage.
3. The epic as a dumping ground. An epic that started as a feature and now holds anything vaguely adjacent. Cost: it stops predicting anything. Nobody can say how close it is to done, so the answer becomes a guess, and the guess goes into a roadmap. Hierarchy is its own subject, covered in how to structure a Jira backlog.
4. The decision in comment 14. The description says one thing and the agreed behaviour sits halfway down a comment thread after two false starts. Cost: whoever reads only the description builds the wrong thing, and they are not being careless. Move the decision up and note that it changed.
5. The reopener. Closed and reopened three times because done was never defined, so each party had a different finish line. Cost: cycle time that looks fine per pass and is dreadful overall, plus the slow erosion of anyone’s belief that Done means anything. See definition of done vs definition of ready.
6. Assigned to a team. The ticket sits against a group or a rotating placeholder account. Cost: nobody starts it, because at no point does any individual feel late. Diffused ownership is not fairness, it is a queue with no head.
7. The eleven-month ticket. Open since last year, never going to be done, and nobody will close it because closing feels like conceding the problem was real. Cost: every count becomes untrustworthy. A backlog holding a hundred of these is a graveyard with a search function.

The last one is the one teams argue about, so be blunt internally. A ticket you would not schedule this quarter or next is not a plan, it is a wish. Close it. If it matters, somebody will raise it again.

How do you write tickets engineers actually understand?

Match the detail to the distance the ticket has to travel, in time and in team distance. A ticket you wrote this morning and will start after lunch needs almost nothing. A ticket picked up in five weeks by a contractor who was not in the room needs context, scope boundaries and criteria, because each of those is a question they cannot ask cheaply.

Ticket hygiene is not free, and over-specifying is its own failure. A thorough ticket takes fifteen to thirty minutes to write, which is a poor trade against an hour of work, and it invites the assignee to implement the description rather than solve the problem.

So write only the parts that would be expensive to ask about later. Which user, what happens on failure, and what done means are almost always in that category. The rest usually is not.

Should developers write their own tickets?

Yes, for their own work, and it is normal on healthy teams. Engineers write the refactors, the upgrades, the flaky test fixes and the follow-ups they spot in review, and those are usually better written than a product manager could manage, because the author knows exactly what is wrong.

The trouble starts with the assumption that whoever writes the ticket also decides the scope. Two different jobs:

• Deciding the work happens and what it is for. Product, usually with the tech lead.
• Writing it down so the next person can act. Whoever holds the detail, which for technical work is the engineer and for a customer-facing change is often whoever spoke to the customer.

The arrangement most teams settle on is that anyone may create a ticket, and nothing enters a sprint without a short conversation that settles scope, ownership and what done means. Refinement exists precisely to catch tickets that read as complete while hiding an unmade decision. If you want a mechanism rather than a habit, Projan puts those questions to the team in Slack or Microsoft Teams and writes the agreed answers out to Jira as a ticket. The questions matter more than the route they take: ask them while the work is still cheap to change.

One rule worth holding either way. Whoever writes the ticket is not the person who decides it is done.

Frequently asked questions

What is the best practice for Jira tickets? Agree a small number of house rules and enforce those rather than a long standard nobody reads. Useful ones: every ticket has a person against it, every ticket in progress has a written definition of done, no ticket carries two outcomes, and the backlog gets a cull on a fixed date. Four rules kept beat twelve ignored.

What is the difference between an issue and a ticket in Jira? Nothing, in practice. Issue was the original Jira term for any tracked item, Atlassian’s documentation now uses work item, and most teams say ticket regardless. The word only matters when you are reading documentation or configuring a project, where the official term is the one that appears in menus and permission settings.

How long should a Jira ticket description be? Long enough that the assignee does not need to find the author, and no longer. For work someone starts today, a couple of lines is honest. For work that sits in a backlog for a month, expect a short paragraph of context, the scope boundary, and checkable criteria. Length is a symptom, not a target.

Who should close a Jira ticket? Whoever can confirm the acceptance criteria were met, which is often not the person who wrote the code. On most teams that is the reviewer, the tester or the person who raised it. Closing your own work is fine when the criteria are objective and someone else has reviewed the change.

Write the title for the person scanning forty of them, write the description for whoever opens it next, and hold one outcome per ticket. If you only change one habit, make it closing the tickets you are never going to do.