USE CASE: It has been requested that defects be created at this sub-task level in Agile Project

[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.

[Stephen_Lugton]

I agree with the principle of separating delivery work and defect remediation work, but how you track it will depend on when it is discovered.

If the defect is discovered during development of a ticket, fixing it should be part of that ticket.

If the defect is discovered in a production environment then it is a bug and a bug ticket should be raised.

If the defect is discovered after you've stopped working on a ticket but before a release into a live production environment, e.g during UAT, then a separate defect ticket can be raised which is an output of the testing phase.  For this case a new ticket type of defect can be created.  The defect can then be prioritised either as a fix before release or depending on the nature of the defect it could be prioritised for fixing in the next release in which case it could be changed to a bug.

[Marcela Junyent]

Thank you for getting back to me!!
I truly appreciate the time you've taken to address my use case!

I believe that it's unnecessary to create a separate issue type for "defects" in addition to "bugs." Based on my knowledge as a System Engineer and Scrum Master, I've learned that an error in the code is a bug, and it can effectively be managed using the bug issue type. All relevant information, such as context, source, severity, and priority of the issue can be included on the bug issue type.

Additionally, the bug can be linked to the affected story. If the bug is blocking the story, the "blocked by" link can be used, and it can include the bug in the current release. Alternatively, it can be linked as a "cause/relates," allowing for the backlog planning of the bug fix for following releases based on its severity and priority.

This approach eliminates the need for an additional issue type. I always aim to have a good reason to create a new issue type, as it would require adding more complexity to track code errors throughout the development process from development to production, having different issue types for the same concept.

[wilfred1005]

substack