How-to Handle Deferred Bugs
During the development of a release, if a bug is found but the CCB decides to fix it in a later version, the bug is deferred. After the official release, it will then be a known bug in the product or system.
This guide describes how to handle deferred bugs and also includes a Q&A with questions related to deferred bugs.
Together with other bug-related guides, it provides information to help ensure the correct handling of all types of bugs. It relates to PCP R&D’s overall bug management process, described in How-to Manage Bugs, as visualized below.
Note: The concept of deferred bugs applies to official releases made available to customers and technology projects. The same workflow should be applied to post-release bugs, with the exception that the reason "Copied to Backlog" should be used to clone them and to assign them to the target release. For L4 bugs, the L4 DoD must be met before taking this action, see DoD for L4 bugs.
Intended for
Configuration managers, product owners, scrum masters, and test engineers.
Activities
Identify target releases
The version to which the bug is deferred may be known or unknown at the time of deferring:
- If the target release is unknown, clone the bug and put it in the backlog.
- If the target release is known, clone the bug and assign it to the identified target release(s). When a deferred bug is planned for a future release, it is considered a scope bug for that release.
Close bug as deferred
Close the bug with the reason "Deferred". Do not change any fields used for planning, such as iteration path or area path.
Note: For post-release bugs, follow the same rule and select the reason "Copied to Backlog".
Clone bug
Note: Steps 1-5 are automatically performed if the "Clone Bug" extension is installed, see Recommended Extensions. The extension is triggered automatically when saving a bug with the state "Closed" and the reason "Deferred" or "Copied to backlog". You can also perform the steps manually by clicking on "Clone as duplicate".
- (Automatic) Clone the bug.
- (Automatic) Add "Clone of bug ID -" to the title.
- (Automatic) Set "ScopeBug=True" in the clone just created.
- (Automatic) Set "Cloned=Yes" in the clone just created.
- (Automatic) Add a link of type "duplicate" / "duplicate of" between the original bug and the clone.
- (Manual) Set the target release, see Area and Iteration Path.
- (Manual) Save the cloned bug.
If the bug affects multiple releases, repeat the steps above for each release as described in How to Manage Bugs in Multiple Releases.
Details
Related fields
Check the Standard Bug Template for more information about the "ScopeBug" and "Cloned" fields.
Q&A
Can I re-open a bug that has been closed as "Deferred"?
No, planning a deferred bug, e.g., deferring it to a known version or putting it in the backlog, means planning its clone, i.e., the copied bug with "ScopeBug=True." If the team can fix a previously deferred bug within the same release (e.g., if the release deadline is postponed), the original bug can be reactivated, and the cloned ones can be closed as obsolete.
Can I close a bug as deferred if I'm not planning to fix it in a future release? No, the reason "Deferred" should only be used for bugs that should be fixed in a future release. Use the reason "Will not Fix" if there is no intention to fix the bug. In the same way, the reason "Will not Fix" should not be used to defer a bug.
Who can defer a bug?
The development teams and product owners can propose to defer a bug by commenting on the bug’s “Discussion field”. However, only the CCB can decide to defer a bug.
Why are some bugs deferred?
There can be many motivations for deferring a bug, such as the required effort to fix or test it, the risk of delaying a release, the availability of resources, or the possible impact on the system.
How to identify known bugs that have been deferred?
After the bug has been deferred and the clone has been created and linked as described above, the original bug can be found by:
- State = Closed.
- Reason = Deferred.
After deferring, cloned bugs will be in the backlog or in a future iteration, and they can be identified by:
- State = Not Closed.
- ScopeBug = True.
- "HowFound" does not contain "Post Release".
How to identify the scope bugs of an ongoing release?
- Bugs are planned for the current release (e.g., by area/iteration).
- ScopeBug = True.
How to identify introduced bugs in an ongoing release?
- Bugs found in the current release (e.g., by area/iteration).
- ScopeBug = False.
How to find the deferred bugs of an ongoing release (for decision-making before releasing)?
Query the bugs found in the release where:
- State = Closed.
- Reason = Deferred.
How to identify known open bugs in a release in production?
Query the bugs found in the release where:
- State = Not Closed.
- ScopeBug = True.
What to do if the deferred bug exists in multiple versions?
Clone the bug multiple times, one for each version where it is known to exist and needs to be fixed. In this way, its fix will be planned and tracked separately.
Is a bug closed with the resolved reason "Will not fix" a deferred bug?
No, this is not a deferred bug. Resolved reason "Will not fix" means that the bug is acknowledged as a defect, but there is no intention to work and fix it in the future.
How can I identify bugs still affecting a released product version?
Query for closed bugs where either:
- Resolved reason = Will not Fix.
- Reason = Deferred.
- Reason = Copied to Backlog.