Bugs do not age well. The longer a defect sits untouched, the more likely it quietly ships. A JIRA bug workflow only works when every status means something, someone owns every transition, and stale bugs get flushed out on a schedule. Here is the workflow my team settled on after trying a much fancier one that mostly produced clutter.
JIRA bug workflow statuses that mean something
Six working statuses, each one an answer to "whose move is it?": Open (needs triage), Triaged (accepted, prioritized, assigned to a release), In Progress (a developer is on it), Ready for QA (the fix is deployed to a test environment — deployed, not merely merged; that distinction has burned me), Verified (QA confirmed the fix), and Closed. Two terminal states, Rejected and Deferred, both requiring a comment explaining why. That is it. If a status does not tell you who acts next, it is decoration — delete it.
Severity and priority are different fields
Severity is impact: crash, data loss, broken flow, cosmetic. QA sets it when filing the bug, and it rarely changes. Priority is when it gets fixed, set at triage, and it is a business decision. A typo in the checkout flow is low severity and high priority; a crash in an admin screen used once a month can be high severity and medium priority. Teams that collapse both into one field end up arguing about the field instead of the bug. Keeping them separate turns "is this a P1?" fights into two short, answerable questions.
Triage cadence
Triage is fifteen minutes, two or three times a week — daily in the run-up to a release. QA, a dev lead, and the product manager. Every bug in Open leaves the meeting as Triaged, Rejected, or Deferred; nothing stays in limbo. Two rules keep it fast: no single bug gets more than two minutes of discussion (if it needs more, someone takes an action item and it comes back with information), and duplicates get linked and closed on the spot.
Preventing zombie bugs
Zombie bugs are the ones open for months, too minor to fix and too real to close, and they slowly bury the backlog signal. My fix is a saved filter: bugs untouched for 30 days. Once a month we walk it, and every bug gets one of three fates — assigned to a release, deferred with a revisit date, or closed honestly as won't-fix. Closing a bug you are never going to fix loses nothing: the report stays searchable forever. It is the open count that lies to you.
Link bugs to test cases
Every verified bug gets linked to the test case or automated flow that should catch it next time — and if none exists, writing one is part of verification. This is how my regression suite grows: not from imagined coverage, but from real failures. Six months in, the suite becomes a map of where the product actually breaks.
Dashboards for release readiness
Four gadgets answer "can we ship?" without a meeting: open bugs by severity for the release version; the count sitting in Ready for QA (my verification backlog — if it climbs, testing is the bottleneck); reopened bugs this cycle (a rising reopen rate means fixes are shipping without enough developer testing); and the found-versus-fixed trend, which should converge as the release date approaches. If it is diverging the week before release, the date is fiction and the dashboard says so before anyone has to.
Adopt this in pieces — separate severity from priority first, then the stale-bug filter, then the statuses. The workflow is just plumbing; the triage cadence is what actually keeps defects moving.