Use Case: Bugs as sub-task created with the 'Defect' name

[Marcela Junyent]

I would like to share my perspective on the process of creating defects at the sub-task level.

It has been requested that defects be created at this sub-task level; however, I have a different preference. Instead of categorizing defects as sub-tasks, I believe it is more effective to classify them as Bugs and include a field that specifies the environment level. This approach will provide valuable information for the development process, particularly regarding the locations where error codes were discovered.

Furthermore, I recommend linking a Bug to a Story to indicate that it "blocks" the delivery of that Story. Utilizing Issue Links is beneficial as it clearly demonstrates that while a Bug may be a dependency for a Story, the work involved in analyzing, fixing, and resolving the Bug remains separate.

This separation allows for distinct delivery based on priority or severity. For instance, a Story can be completed even if it has a minor defect, whereas a production bug may not always be addressed immediately. I also find it advantageous to track Bugs and Stories concurrently on a board, as the Issue Link effectively treats the Bug as a "sibling" of the Story.

I also think that will allow better reporting without complex filters in native dashboards or EasyBi.

I firmly believe that using Subtasks with “defects” name is not the correct approach and can lead to a complex reporting environment. I would greatly appreciate hearing your opinions and observations to help me make the most informed decision regarding this matter. Additionally, I think it would be beneficial for my team to understand the reasons why using subtasks may not be the best strategy.

[John Funk]

Hi Marcela,

Thanks for starting the discussion. And because it is a discussion, I respectfully disagree with you. :-)

Here's my take on it. First, some definitions.

A defect is something that has been found during the testing process (by QA analyst or others) and should prevent the Story/Task from being deployed.

A bug is something that has been found during the testing process but is not something that should prevent the Story/Task from being deployed. We will fix it later because it is minor. Or a bug is something that is found in the production system/app/software - either by a customer or we find it ourselves. 

Either way, a bug is created and added to the backlog to be fixed later (or now). 

So in my scenario, a Defect is a different animal than a Bug. And the defect is a sub-task to the original Story/Task it is associated with. And if you have your workflow set up so that you cannot move a Story/Task to Done if there are open Sub-tasks, then the Defect is preventing the Story/Task from being deployed. Just as intended. 

A Bug sits at the same level as a Story/Task. And as such can be tracked and reported on, separately from Stories and Tasks and Defects. 

Those are my two cents.  :-)