Don't let bugs escape your triage net
Within your team’s Definition of Done across user stories there will be a section on conducting thorough testing, and fixing any bugs that are found. Fixing the bugs can be a tricky topic as it's usually the product owner’s or the team’s responsibility to triage the bugs identified in each user story, and decide which ones need fixing. Any bugs that won't be fixed as part of the story are placed on the backlog.
Sometimes stray bugs miss your team’s triage process, but you can set up the following workflow in Jira, to enforce that bugs reported during user story testing are triaged before the user story can be completed or closed.
A feature of Jira’s workflow functionality is the ability to enforce the rule that an Issue cannot be transitioned (e.g. closed) while it has open sub-tasks. By enabling this rule on your project’s workflow, and reporting defects found during testing as a sub-task of the user story under test, you can enforce that the triage process is followed.
For the sake of clarity to users, it's best to have a dedicated sub-task issue type for reporting bugs; we recommend using 'defect or 'bug' in the name of the new issue type, e.g. 'Story defect' or 'Story bug'.
Example workflow from the user’s perspective
Let's consider an example, a user story with two defects found during testing and reported using the 'defect' sub-task. If the developer tries to close the user story, it won't close because it has open sub-tasks from the defects. This forces actions to be taken - the developer talks to the product owner and tester to triage the identified defects.
For the first defect, the product owner decides it is a major increase in story scope and should be placed on the backlog as there is little impact to the value delivered. To do this, the product owner converts the 'defect' issue from a sub-task to a full Issue in your backlog, with the appropriate type for bugs. This means the user story only has one sub-task remaining.
For the second defect, the product owner feels it is important to the story and must be fixed before the user story can be considered 'done'. The ‘defect’ sub-task is simply assigned to the developer, who updates and transitions (i.e. to Closed) the sub-task once the fix has been implemented. Now that this second sub-task has been closed, the developer will be able to close the user story and it can be considered 'done'.
Whatever happens, this simple workflow implementation enforces that a decision is made, and Jira captures a full audit trail of the process.
Configuring the workflow in Jira
To configure this way of working in Jira you need to make two simple changes:
Add the "All sub-tasks must have one of the following statuses to allow parent issue transition" condition to the 'close' transitions in your projects workflow.
Create a sub-task issue type to represent the defect and add it to your projects issue type scheme.
Then you can proceed to setting it up.
Adding the workflow condition
Open the 'Cog menu icon' and choose Issues. Select Workflows from the left-hand navigation to open the Workflows page.
Find the workflow your project uses and select Edit from the Actions column.
Find the transition you want to enforce the rule on, and open it.
Open the Conditions tab and review the existing conditions. If no rule for “All sub-tasks must have one of the following statuses to allow parent issue transition” exists, click Add condition.
Select Sub-Task Blocking Condition and click Add. On the next page select the status the sub-task must be in before the parent issue will successfully transition, and click Add.
Your workflow modifications will currently be in a draft form and you will need to select Publish before they take effect on your project.
Creating a new Sub-Task issue type
Open the 'Cog menu icon' and choose Issues. Select Issue Types to open the Issue Types page.
Click Add issue type button to open the Add Issue Type dialog box.
Add an appropriate name (e.g.” Story defect”) and select Sub-Task Issue Type before clicking the Add button.
This will create the new sub-task issue type, but it won't be available in your project until you add it to the correct Issue type scheme.
Choose Issue type schemes from the left-hand navigation.
Find the Issue type scheme associated with your project and click Edit from the Actions column.
Find your sub-task under Available Issue Types and drag it across to Issue Types for Current Scheme. Then click Save.
Congratulations, you've configured the full workflow! From now on, no bugs found during user story testing should slip through the net.
You may also like…