Atlassian's AI features got substantially better this year, and a fair number of teams are about to conclude they didn't.
That gap is worth understanding, because it usually isn't the model's fault.
The two backlogs
Pull up a sprint from six months ago and be honest about what's in it.
There's a ticket called "fix login bug" whose entire description is "see Slack thread." There's a near-duplicate two days later called "login broken again??" with nothing in the body. There's a third called "auth stuff" that says "same as 418 I think." Nobody wrote acceptance criteria because everyone was in the room when it was discussed, and the room remembered.
The room does not remember. And an assistant reading those three tickets has almost nothing to work with. Ask it what the login problem is and you get something that sounds like an answer — "the login issue appears related to authentication; consider checking the auth service" — because that is genuinely all that's in there. It isn't hallucinating. It's summarising three sentences of real information into one sentence of real information.
What the ticket lost wasn't in the ticket. It was standing around it (Fig. 1).
A ticket reading “fix login bug — see Slack thread” shown at three points in time. Its text is identical at all three. Around it, the Slack thread ages out of retention, the standup that defined the term disperses, the author changes team, and the shared assumption stops being shared — until the ticket means exactly and only what it says.
Everything the room knew.
Now write the same three tickets to a shape, and ask again (Fig. 2).
An interactive comparison. Two versions of the same three tickets — one written thinly, one written to a four-field shape — and the answer an assistant returns for each when asked what the login problem is. The thin version yields a restatement of the input; the structured version yields a root cause and an order of work.
- Description
- see Slack thread
- Description
- —
- Description
- same as 418 I think
“The login issue appears related to authentication. Consider checking the auth service and reviewing the linked discussion.”
- no root cause
- no ordering
- restates the input
The assistant did not get smarter between those two answers. It got something to read.
Why this is worth more than it was
Two things changed recently and they push the same way.
The first is that AI in the Atlassian stack can now do cross-issue reasoning — connecting a bug to its cause, ordering work, spotting duplicates. That capability has a floor set by your data. A tool that reasons across issues only pays off if your issues contain something to reason across (Fig. 3).
A table of the things two issues could be matched on — four ticket fields and four domain terms — checked against the same three issues written two ways. In the typical backlog no row is carried by two issues, so there is nothing to join and every apparent link is a human pointer a retrieval step cannot follow. In the structured backlog 8 rows are shared by two or more issues.
“See Slack thread” and “same as 418 I think” are real pointers — a colleague follows them without noticing. Neither is a link, a key, or a term, so nothing that retrieves can.
The second is that coding agents consume tickets directly, which changes the cost of a thin ticket in a way most teams haven't priced in. A person handed a vague ticket asks you a clarifying question. An agent handed the same ticket doesn't — it produces a confident, plausible answer to the question it decided you were asking. That's a separate argument, but it lands in the same place.
Ticket structure used to be a courtesy you extended to your future colleagues. It is now also the input format for tooling you're paying for.
What I can't show you
I'd rather you trusted the parts of this that hold, so: I can't point you at a study proving that teams with consistent tickets get measurably better AI output. As far as I can tell nobody has published one.
What I can say is that the mechanism isn't mysterious — retrieval and summarisation over sparse, inconsistent text produces sparse, inconsistent results — and that it's cheap to test. Take ten well-written tickets and ten thin ones, ask your assistant the same question of each set, and read the two answers side by side. Twenty minutes, and it tells you more about your situation than I can.
The second honest caveat is that structure has a cost. Reproduction steps, acceptance criteria and explicit out-of-scope boundaries take real minutes, and "just write better tickets" is advice that has been failing teams for twenty years.
It fails because it's a throughput problem wearing a knowledge problem's clothes. Everyone already knows what a good ticket looks like. They write bad ones anyway, at 4pm, with thirty-eight left to go.
The shape
Four fields is plenty (Fig. 4). A shape people can hold in their head beats a comprehensive one nobody fills in.
What is happening, where, and how to see it
Lets the assistant locate the work in the codebase
The conditions under which this is done
Turns review from inference into checking a list
Which components are in play, which patterns to follow
Stops the blast radius widening on its own
What not to touch
The field that prevents the surprise refactor
Three things make it stick, none of which are discipline:
Put it where the ticket is created. Not in a Confluence page linking to a Google Doc. If someone has to go and find the standard, the standard loses to the deadline every time.
Fix forward. Do not launch a backlog cleanup project; they die around week three. Apply the shape to new work and let the old stuff age out of relevance on its own.
Generate the repeated parts. Most of what goes into a well-formed ticket is repetition — the same acceptance-criteria skeleton, the same constraint boilerplate, the same out-of-scope defaults for a given component. That's transcription, not thinking, and transcription is exactly where the discipline breaks.
That last one is what we build SuperTemplates for: structured issues generated in bulk, so the well-formed version is the fast version rather than the virtuous one. The first two are free and they're most of the value.
The takeaway
The AI in your Jira will be about as good as your Jira.
That isn't a complaint about the AI. It's the most actionable thing about it — because unlike the model, the input is yours to change.