Defects

Defects are part of the process. There are defects discovered during the quality check of a completed technical task—before the task is considered finished—and those found either during or after the implementation of an Objective.

1. During the quality control stage, defects in the implementation of technical tasks may be identified. In such cases, the task is returned to the executor for correction.
2. Defects found during or after the implementation of an Objective: we log the problem, investigate what went wrong, and determine who will fix it—either by returning the task to the responsible person or identifying someone with the required expertise to resolve it.

Types of Relationships:

• Breaks: 

Critical Relationship: The detected defect breaks critically important functions/capabilities of the stream. For example, if a defect affects the ability to log in to the application, the relationship type for Defect to Objective would be "Breaks."

Priority Calculation Logic: Adds +1 to the existing business weight of the Objective.

• Degrade: 

Minor Relationship: The detected defect affects the stream's functionality/capabilities, but these functions/capabilities are rarely used or seen; hence, fixing the defect is not critically necessary.

Priority Calculation Logic: Subtracts -1 from the existing business weight of the Objective.

Impact on Assigning Executors

The connections of a defect play a crucial role in assigning the right person to fix it:

• If the task that introduced the defect is known: Priority is given to the person who worked on that task. This approach is based on the fact that the person who introduced the defect best understands the problem's context. However, the priority may be adjusted if fixing the defect requires higher skills (e.g., senior-level expertise).