Bug Tracking in Jira: A Setup That Stays Clean

Jira bug tracking stays clean when bugs have their own short workflow, a handful of required fields, and one person who triages them on a fixed day. Give the Bug work type five statuses (Triage, To Do, In Progress, In Review, Done), set a resolution whenever a bug closes, add a Severity field because Jira does not ship one, and keep everything else optional. Most messy Jira bug backlogs are not a tooling problem. They are a backlog nobody is allowed to close.

Bug tracking, defect tracking, bug management: one job

Teams call it a Jira bug tracking system, Jira defect tracking or Jira bug management, and they mean the same thing: every defect becomes a work item of the Bug work type, with a key such as PAY-212, a status and a history. A note on words: Jira Cloud now calls issues work items, issue types work types and projects spaces. The setup below works in either kind of space, though company-managed spaces give you shared workflows and components that team-managed spaces do not. If you only need to choose a tool, the comparison lives in bug tracking tools; this page is Jira setup only.

A bug workflow with five statuses

Atlassian defines a Jira workflow↗ (opens in a new tab) as a set of statuses and transitions that a work item moves through, and a workflow scheme lets you give bugs a workflow of their own without touching stories and tasks. Use that. A bug needs one step a story does not: somebody has to decide whether it is real before anyone works on it.

Triage       New bugs land here. Nobody works on them yet.
  -> To Do        Accepted: real, reproducible, prioritized
  -> Done         Closed at triage (resolution: Duplicate,
                  Cannot reproduce or Won't do)
To Do        -> In Progress
In Progress  -> In Review      Fix written, waiting for review or QA
In Review    -> Done           Fixed and checked (resolution: Done)
In Review    -> In Progress    Failed review or retest
Done         -> To Do          Reopen, with a comment saying why

Two rules make this hold. First, every transition to Done sets a resolution, because a bug closed as a duplicate and a bug that was fixed are different facts, and reports cannot tell them apart otherwise. Atlassian’s page on statuses, priorities and resolutions↗ (opens in a new tab) lists Done, Won’t do, Duplicate and Cannot reproduce among the defaults and notes that a resolution is usually set when the status changes. Second, nothing skips Triage. The full set of states and who moves them is in our bug life cycle guide.

The fields a Jira bug needs, and the ones it does not

Every required field is a reason for a tester or a customer not to file. Require three, show five more, and hide the rest from the bug create screen.

• Title (required). Where and what: “Checkout: ZIP+4 codes rejected at the shipping step.” Jira labeled this field Summary until recently.
• Description (required). Steps to reproduce, expected result, actual result. Put a template in the field’s default text; our bug report template has one to paste.
• Environment (required). Browser, device, app version or build. Without it, a bug that only happens on one phone gets closed as “cannot reproduce” by someone testing on a laptop.
• Severity. How bad the defect is. A custom field; see below.
• Priority. How soon you will fix it. Set at triage, not by the reporter.
• Component. The product area, so the right person sees it. Company-managed spaces only.
• Affects versions and Fix versions. Which release has the bug, and which one will carry the fix. Skip them if you deploy continuously and do not name releases.
• Labels. Two or three agreed values at most, such as regression and customer-reported.

Leave out story points, due dates, sprint on create, and any free-text field that duplicates the description. If a field has been empty on most bugs for three months, nobody needs it.

Severity vs priority in Jira

Jira has Priority (Highest, High, Medium, Low, Lowest by default) and no Severity field in a software space. That is a deliberate choice: an old Atlassian administrator FAQ, why JIRA does not have a severity field↗ (opens in a new tab), says it was removed “principally because it was confusing to business users” and suggests a custom select-list field instead.

Add it if your bugs come from testers or customers, because they can judge how bad a defect is but not how soon you will fix it. A Jira admin can create a custom field↗ (opens in a new tab) of the single-select type, call it Severity, give it four options (S1 Critical, S2 Major, S3 Minor, S4 Trivial), and add it to the Bug screens only. The reporter sets severity; the triager sets priority. When the two disagree, that is the conversation triage is for. The matrix and examples are in bug severity vs priority.

Triage: one owner, one sitting, four outcomes

Save the triage queue as a filter and put it where the triager starts their day, such as a Filter Results gadget on a Jira dashboard:

space = PAY AND type = Bug AND status = Triage ORDER BY created ASC

Work it oldest first, once or twice a week for most teams and daily when a release is close. Each bug leaves Triage with one of four outcomes, and none of them is “leave it for later”:

1. Accept. It reproduces. Set severity if the reporter did not, set priority, and move it to To Do.
2. Ask. It might be real but the report is thin. Comment with the exact question and leave it in Triage. If there is no answer after two weeks, close it as Cannot reproduce.
3. Merge. It is a duplicate. Link it to the original, close it as Duplicate, and comment on the original that another person hit it.
4. Decline. It is working as designed, or not worth fixing. Close it as Won’t do with one sentence saying why, so the reporter is not left guessing.

A checklist that keeps a Jira bug backlog clean

• Bugs have their own workflow with a Triage status, assigned through a workflow scheme.
• Three required fields: Title, Description with the template, Environment.
• Severity set by the reporter, priority set by the triager.
• Every close sets a resolution. No bug is closed by moving it to Done with nothing selected.
• One named triager per week, and the triage queue is empty at the end of the sitting.
• A monthly sweep: space = PAY AND type = Bug AND resolution = unresolved AND updated < "-90d". Fix, re-prioritize or close each one as Won’t do.
• Reopening means a comment that says what failed and in which build, not a second bug.

A simpler alternative for small teams

Everything above is configuration: schemes, screens, custom fields and a status somebody has to add. For a team of a few people, that can be more upkeep than the bugs themselves. fenbs takes the opposite approach and fixes the shape. A bug is one of three kinds of task, with a ref such as BUG-014 that is never reused. It has a priority from 1 to 10, where 1 is the most urgent, and moves through four lanes: To Do, Next Up, In Progress, Completed. The note holds the report, the plan holds the fix, and a test status with test notes says how it was checked.

Closing records how a bug ended as well as where it is: Completed, Won’t fix, Duplicate, Cannot reproduce or Obsolete. Testers and customers can be added with the Reporter role, which lets them file bugs and comment and edit only their own, without moving anyone’s work. An AI assistant connected over MCP can triage what came in overnight, and the History page shows each change it made under its own name. What you give up: no custom fields (so no separate severity field), no workflows to configure, no sprints and no settable assignee. The bug tracker template is a ready board, and fenbs vs Jira has the side-by-side.