What a zombie ticket is
A zombie ticket is an open ticket that looks alive but that nobody is really working on. It still sits on the board, it still counts as open work, and it still shows up in every report. But nobody has changed it in a meaningful way for a long time, and nobody plans to.
Zombies are not a sign of a bad team. They come from normal habits: a ticket started and then dropped for something urgent, a "we will do it later" that became never, a duplicate that nobody closed, a story whose subtasks are all done but whose parent stayed open.
Why "last updated" misleads
The obvious way to find stale work is a filter on the "updated" date. It misses many zombies, because a ticket is updated by more than people. An automation rule that adds a label, a bot that posts a comment, a bulk edit that touches a hundred tickets: each one resets the date, and the ticket looks fresh.
A better question is: when did a person last do something that moves the work forward? Changing the status, the assignee, the resolution or the description, or writing a comment. Edits by bots, automation and bulk label changes should not count.
Six signs of a zombie
These six rules catch most of them. The numbers are sensible starting points, and every team should tune them.
- Stuck In Progress: the ticket is In Progress but nobody has touched it for 14 days or more.
- Frozen: no real activity at all for 60 days or more.
- Contradiction: it carries a label such as wont-do, duplicate, obsolete or cancelled, but it is still open.
- Carried over: it went through two or more closed sprints without being finished.
- Empty stub: it has had no description for a week or more, so nobody can tell what "done" means.
- Finished parent: every subtask is done, but the parent is still open.
One more signal is not about a ticket but about a person: someone with more than five tickets In Progress at once is probably not working on all of them.
Why it matters
Zombies are not harmless clutter. They make the backlog look bigger than it is, so planning starts from the wrong number. They inflate In Progress counts, which hides where work is really stuck. They pull sprint reports and velocity away from reality, and every forecast built on them inherits the error. They also cost attention: each time someone scans the board, they read the same dead tickets again.
It helps to have one number. A simple score is the share of open tickets that are not zombies. Above 80 out of 100 the backlog is healthy; between 50 and 79 it needs attention; below 50 you have an outbreak.
How to clean up safely
The fastest cleanup is a bulk close, and it is also the riskiest. A few habits keep it safe:
- Close with a reason. Add a comment that says why the ticket was closed, so anyone who finds it later understands, and can reopen it.
- Follow the workflow. Move tickets through the real transitions to Done instead of forcing a status.
- Check it has not changed. If someone touched the ticket after you reviewed the list, leave it alone.
- Look before you close. A flagged ticket is a candidate, not a verdict. Someone should decide, ticket by ticket.
- Repeat. A one-off cleanup fades in a few months. A daily or weekly scan keeps the score up.
Doing it in one click
We built Zombie Hunter for Jira, an app that finds and closes stale tickets to do exactly this. It checks every open ticket in a project against the six rules above, counts only real activity, gives the project a health score from 0 to 100 and lists the zombies with the rule they broke and the days they have been idle. A project admin can change every threshold.
When you decide a ticket is dead, Close moves it to Done as you, steps through your workflow if it has to, and adds a comment that explains why. If the ticket changed since the scan, it is left alone.
The app runs on Atlassian Forge, so its data stays in Atlassian's infrastructure for your Jira site, and nothing is sent to us. The Zombie Hunter user guide explains each rule, and the privacy policy lists the data it keeps and the permissions it asks for.