Every engineering team has a JIRA graveyard. Tickets created without descriptions. PRs merged without links. Fields filled in wrong, or not at all. Subtasks scattered across sprints with no parent. The board that stopped reflecting reality weeks ago.
The standard diagnosis: the team doesn't follow the process. The standard fix: another retro, another Confluence page, another reminder in Slack.
That doesn't work. Here's why.
JIRA hygiene degrades when the cost of bad data falls on someone other than the person creating it.
The engineer who skips the ticket description pays no immediate price. The PM trying to scope next quarter, the engineer picking up the ticket cold, the manager running the retro - they pay the price. It's a classic externality problem. The person creating the mess isn't the person cleaning it up.
Process reminders don't fix externality problems. They just add friction to the people who were already doing it right.
What actually works: make the source of truth matter.
In a recent sprint review, I traced a set of field scope creep issues back to tickets that were created without proper scope definitions. Not because engineers were cutting corners - because the ticket wasn't the source of truth. The actual scope was in a Slack thread, or a meeting, or someone's head.
The fix wasn't a new process. It was a decision: JIRA is the source of truth. Not Slack, not Confluence, not verbal agreements. If it's not in the ticket, it doesn't exist. PRs must link to tickets. Scope changes must be reflected in the ticket before they're worked.
When JIRA is actually the source of truth, the incentive flips. Now the cost of a bad ticket falls on the person who created it - their PR won't get reviewed without a linked ticket, their scope change won't be tracked, their work won't be visible.
The leadership part.
This only works if leadership enforces it consistently. Not as a bureaucratic rule, but as a standard of craft.
The message isn't "fill out the fields." It's "we make decisions from this data. If the data is wrong, our decisions are wrong. That's on all of us."
Engineers who understand why it matters don't need reminders. They need to see that leadership takes the standard seriously - which means rejecting PRs without ticket links, asking for scope updates in real time, not retroactively at the retro.
JIRA hygiene isn't a process problem. It's a signal of how seriously your team takes shared context. That comes from the top.
TL;DR
- JIRA degrades when the cost of bad data falls on someone other than the person creating it
- Process reminders don't fix externality problems - make JIRA the actual source of truth
- When JIRA is the source of truth, incentives flip: bad tickets create friction for the person who made them
- Engineers don't need reminders when they understand why shared context matters - but they need to see leadership enforce the standard