Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Effective Techniques For Bug Tracking In JIRA

What are some effective ways to perform bug/defect management using JIRA?  


One method we developed is that once a bug/defect is discovered, a bug issue type is created.  The bug issue type is put into an In Development status, and then once a resolution to the bug is determined, the bug issue is moved to a Complete status, and a corresponding User Story is created for the development required to fix the bug.

My thoughts are, however that this creates a little extra work, and instead, log the defect by creating a bug issue, and update its workflow status as it progresses from identification, to development, to testing, to production release, and then updating the bug to complete.

Not sure if closing out the bug and creating a user story to address development for fixing the bug is the most efficient and effective bug management process using JIRA.

How do you manage defects using JIRA? 

1 comment

Jimi Wikman
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Jun 12, 2022

First, separate Incidents from defects.

Incidents come from production and defects are found in testing during development.


Defects I usually add as sub-tasks in the story, effectively blocking it from being closed until the defect is either resolved, or lifted out as a stand-alone defect (known defect). For exploratory defects, I add them as stand-alone defects unless it is known what story they are releated to.

Incidents are always stand-alone, and the issue type identify them as Incidents and the Priority is the Incident priority connected to SLA.

Incidents and Defects have the same workflow as development, but with 2 additional statuses: Triage and Rejected. Triage is where you do incident/defect management to verify the reported incident or defect. Rejected is the soft close that allow people to improve the report if it can not be reproduced.

You can see an example of this in my old presentation on designing for Atlassian:


Log in or Sign up to comment