Skip to main content

DoD for L4 Bugs

The definition of done (DoD) for L4 bugs are the checks performed when an L4 bug is considered completed.

The product owner and L4 coordinator are responsible for L4 bugs, and the DoD helps them assess the completeness. DoD needs to be fulfilled before a bug is no longer considered an L4 bug.

What is an L4 bug?​

An L4 bug is a customer problem escalated to L4/R&D by support level 3 using a bug in Azure DevOps (ADO).

Then it can only be considered as such if:

  • A customer is suffering from it.
  • A solution or workaround has not been identified.
  • The problem is related to a released product (G5 passed).
  • The issue is not considered by R&D as product enhancement request.

Please, note that following issues are not considered L4 bugs:

  • Issues coming from pilot projects (since such issues are linked to products not released).
  • Documentation issues related to L4 bugs, raised by L3 Support in relation to an L3 case management (this can happen if L3 Support close a case with a configuration change and later open a new work item to suggest a documentation change to better describe the configuration, based on the L3 case closure experience).

DoD for L4 bugs​

There are two alternative ways for an L4 bug to fulfill DoD:

  1. An investigation has been done, so that:

    • CCB has enough information to decide whether the bug should be corrected (not yet necessarily decided in which version) or not.
    • A product issue number (PIN) has been generated and added to the bug if applicable.
    • L3 has enough information (from an R&D perspective) to de-escalate the corresponding Salesforce case.

  2. The Salesforce case is closed (the customer has a workaround etc.) after an L4 bug has been created by L3.

When the DoD is verified, the bug will cease to be an L4 bug and continue as a regular bug. It will no longer be part of the L4 backlog or statistics.

L4 bug identification​

L4 bugs can be identified when the following conditions are satisfied:

  • The bug is linked to at least one Salesforce case.
  • The bug is not categorized as enhancement.
  • The bug is not a clone of another bug.
  • The status of the bug indicates that initial investigation is not completed and/or a CCB decision is to be taken.

The "External Reference" field, which is a part of the Standard Bug Template, contains the link between the bug raised in ADO (L4 bug) and Salesforce (customer) case. Then, if the same issue is suffered by many customers there will be a single ADO item linked to many Salesforce cases.

L4 bug age count​

Age count for L4 bugs:

  • Begins when one of the following conditions is satisfied:
    • The bug is created by L3 as L4 bug.
    • An existing bug (not L4 bug) is linked by L3 to a Salesforce case and become an L4 bug
  • Ends when one of the following conditions is satisfied:
    • The bug is closed as “Copied to Backlog” and cloned to the targeted release proposed to the customer (see How to Handle Deferred Bugs).
    • The bug status indicates that the investigation is complete and a CCB decision has been made. If a targeted release has already been assigned (e.g. started as an internal bug and was later linked to a Salesforce case by L3, becoming an L4 bug) this status will reflect that.
    • Bug is resolved with a workaround or a configuration change (information provided, to be verified on site).
    • Bug is closed as rejected.

NOTE: Refer to How to Handle Bugs in Multiple Releases if the bug must be addressed in multiple release (e.g. a TC is requested and the fix will also be included in the next release). Please note that this will not affect the age count.

Owner: L4 and Maintenance Team