Overview | ||||
---|---|---|---|---|
Definition (Hover Text) | measures Measures ratio of the total number of defects (bugs) linked to closed stories and the size of a closed stories | |||
Source Tools | Jira, Azure | |||
Graph type | Line Chart | |||
Filters | <None> | |||
Hover Format on KPI | Sprint Name: <<Percentage Value>> Defects: <<Value>> Total Size of Closed stories : <<Value>> | |||
Fields on Overlay |
| |||
Business Logic | ||||
Calculation Formula | No. of defects tagged to all stories closed in a sprint/ Total size of stories closed in the iteration | |||
Trend | Positive trend indication - DecreaseA downward trend in DD is desirable. This means fewer defects are being injected over time. | |||
Maturity Levels | DD maturity is assessed by averaging data from the last 5 sprints. This helps in understanding the stability and improvement over time. M1: > 90% M2: 60% -90% M3: 25%-60% M4: 10-25% M5: <10% *Please note:- KPI widget denotes the average maturity over data points | |||
Instance level thresholds | Target KPI Value denotes the bare minimum a project should maintain for a KPI. | |||
Global Configurations- (Field Mapping) | ||||
Processor Fields | Whenever we update the defect mapping and issue type mapping, whether we add or remove any issue type, we must run the processor. This is necessary to show the changes in the KPI. Defect Mapping :
| |||
Mandatory fields
| Project Settings
Defect Mapping :
Issue type Mapping :
| |||
How to Validate KPI | ||||
Suggested ways of working | This measures the ratio of the total number of defects (bugs) linked to closed stories and the size of those closed stories.
| |||
Sample JQLs | project in ("XYZ") and component =ABC and type in (Defect) and issueFunction in linkedIssuesOf("type in (Story) AND sprint in(406)") project in ("ABC") AND component = "xyz" AND type in (Defect) AND issueFunction in linkedIssuesOf("type in (Story) AND sprint in (40756)") AND status NOT IN (Rejected, Dropped, Abandoned) | |||
Best Practices | ||||
Automate Testing | Implement automated testing (unit, integration, and end-to-end tests) to catch defects early in the development process. | |||
Pair Programming | Implement pair programming to increase code quality and reduce the likelihood of defects being introduced. | |||
Adopt TDD/BDD | Use Test-Driven Development (TDD) or Behavior-Driven Development (BDD) methodologies to write tests before code, ensuring that functionality is well-defined and tested from the start. | |||
Use Static Analysis Tools | Implement static code analysis tools to automatically check code for potential defects and enforce coding standards. | |||
Benefits of KPI | How does the KPI help | The Defect Density KPI measures the number of defects per unit of code or product, helping teams improve product quality, reduce costs, and increase customer satisfaction by identifying areas for improvement and prioritizing testing efforts.|||
Quality Measurement | It helps in measuring the quality of the code being produced and identifying areas where improvements are needed. | |||
Predictability | Understanding the defect Density can help in forecasting the amount of rework required and in planning more accurately. | |||
Cost Reduction | Reducing the Defect Density can lead to lower costs associated with fixing bugs, especially those found later in the development cycle or after release. | |||
Process Improvement | By tracking this metric, teams can identify stages in the development process where defects are commonly introduced and take steps to improve those stages. | |||
|
|
Page Comparison
General
Content
Integrations