Jira Backlog Personalities: Ghost Tickets, Drama Epics and Other Red Flags

At some point after spending far too much time staring at Jira backlogs, I developed a theory.

A backlog is basically a dating app for questionable software decisions.

You have the ghosts, the over-sharers, the commitment-phobes and the ones that look manageable until you open them and discover seventeen hidden dependencies. Occasionally, there is rumoured to be a quiet little ticket that will improve everybody’s life without causing three weeks of emotional damage.

I have encountered all of these in the wild.

If Jira tickets were allowed to create dating profiles, I imagine the experience would look something like this.

The Ghost Ticket

Bio: “No description. No context. Just vibes.”

This profile catches your attention with a title such as “Fix issue” or “Update screen.” You open it, hoping the description will explain which issue or which screen.

There is no description.

There may be a priority, though. It is usually High. Sometimes Highest, because whoever created the ticket wanted to ensure that the mystery received the urgency it deserved.

The creator is no longer at the company. The assignee is either blank or you. Somehow, it is frequently you.

You swipe left, but the ticket remains in the backlog because Jira has a very different understanding of rejection.

The Ancient Feature Request

Bio: “I’ve been waiting since 2021, but I still believe in us.”

The Ancient Feature Request was created by somebody whose profile picture no longer loads. It has passed through several product strategies, at least one organisational restructure and possibly an entire global event.

Nobody remembers why it was requested, but closing it feels strangely disrespectful. What if it was important? What if a stakeholder returns after five years and asks why the button never became slightly rounder?

When I inherit these tickets, I move them aside while I gather context. Over time, some are updated and returned to society. Others are quietly removed once everyone agrees that we are no longer building the product described in a planning meeting from another era.

Until then, they wait patiently, confident that their sprint will come.

The Drama Epic

Bio: “I’m complicated, but I promise I’m worth it.”

Its title is something modest such as “Improve Performance” or “Update User Experience.” The description contains one sentence. The estimate contains the hopes and dreams of somebody who will not be implementing it.

Everyone agrees the epic matters. Nobody agrees on what completion would look like.

The Drama Epic has no boundaries. Every conversation reveals another feature that was apparently always part of the plan. You thought you were improving one screen, but now there is an API migration, a database change and a brief discussion about rebuilding authentication.

You do not discover the full scope on the first date. The Drama Epic prefers mystery.

The Over-Sharer

Bio: “Before we begin, please read my 14-page attachment.”

This ticket would like you to rename a button.

It contains screenshots, arrows, design notes, meeting history and a detailed explanation of how buttons work. The acceptance criteria have subheadings. Somewhere in the comments is a document explaining why the original document was not sufficiently clear.

I used to think tickets like this pointed to a trust gap. Now I am less convinced. Sometimes the writer has lived through too many misunderstandings and refuses to be hurt again. Sometimes compliance requires the evidence. Sometimes anxiety has taken control of the keyboard.

And sometimes a person simply loves documentation with an intensity the rest of us cannot match.

You admire the effort, open the ticket and immediately need a small break.

The Returning Bug

Bio: “I’m different now.”

You have closed this bug before. The team celebrated. Somebody added a test. The release went out and, for a few peaceful days, everybody believed the relationship was over.

Then it returned with a new ID.

The reproduction steps are slightly different, but you recognise the behaviour. It is wearing a hat and hoping nobody notices.

By the third reopening, the bug has become part of the team. It attends sprint planning, appears in retrospectives and gets mentioned during releases as though it has its own seat at the table.

Nobody is fixing it anymore. You are managing a long-term relationship.

The Friday-Afternoon Bug

Bio: “Looking for someone spontaneous.”

This bug appears in production at 16:55 on a Friday.

It is small enough that somebody says, “This should be quick,” which is how it chooses its victim. Twenty minutes later, three developers are on a call, one person is reading logs and somebody has used the phrase “That should be impossible.”

The bug has no interest in your weekend plans.

It will briefly disappear when observed, return during the demonstration and resolve itself the moment somebody suggests rolling back. On Monday morning, it will behave perfectly.

You will never receive closure.

The Pet Project

Bio: “Nobody asked for me, but I’m fun.”

The Pet Project ticket was created late at night by a developer who had an idea and access to Jira.

There is already half a branch. Nobody approved the work, but there is a surprisingly polished proof of concept and the creator would like five minutes at the end of sprint planning to explain why it could change everything.

The ticket is not connected to the sprint goal, the roadmap or any known customer need. It is, however, shiny.

Sometimes these ideas become genuinely useful. Sometimes they become a repository last updated eleven months ago. Either way, somebody had a lovely evening.

The Tiny Ticket With a Secret

Bio: “Low effort. Very relaxed. Definitely no complications.”

The title sounds harmless. The description is short. The estimate is tiny.

Then you begin the work.

The button is controlled by a shared component used on fourteen screens. The copy comes from a translation service. The analytics event was named by somebody who considered spelling optional. Changing the colour requires updating an ancient theme file guarded by tests nobody understands.

The ticket did not technically lie. It simply allowed you to make assumptions.

This is Jira catfishing.

The Hidden Gem

Bio: “I’ll quietly make everything better.”

I am told these exist.

According to legend, the Hidden Gem is a small, well-described ticket with clear value, no unexpected dependencies and a reasonable estimate. Completing it improves the developer experience, makes users happier and causes no production incidents.

I cannot currently recall meeting one personally, but I remain open to the possibility.

Perhaps mine is still marked Low Priority, waiting for me to stop matching with drama epics.

The Backlog After the Swiping Ends

The dating-app comparison is not something that genuinely occurred to me during one profound backlog-refinement session. I developed it later, after enough years of seeing the same ticket personalities appear across different teams and products.

A backlog rarely contains only neat, current and perfectly explained work. It collects abandoned intentions, urgent mysteries, duplicated ideas and requests nobody feels authorised to close. Some tickets are genuinely important. Others survive because deleting them feels more dangerous than ignoring them.

Eventually, somebody has to begin swiping.

The vague ticket needs context or closure. The ancient feature request needs to prove it still belongs in the current product. The drama epic needs boundaries, and the tiny ticket needs to admit what it has been hiding.

Not because the backlog is a profound reflection of organisational culture. Sometimes Jira is simply messy because humans are messy, priorities change and nobody wants to spend Friday afternoon cleaning up tickets created in 2021.

Mostly, though, refinement becomes easier once you accept that not every profile deserves another chance.

Some tickets need commitment.

Some need therapy.

Some need to be unmatched forever.