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

1. Sprint Name

2. Story ID

3. Issue Description

4. Linked Defects to Story

5. Size(story point/hours)

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 - Decrease

Maturity Levels

1. Numerator :

   • This is the count of defects (bugs or issues) that were found in all the stories that were completed in a sprint.

2. Denominator :

   • This is the total size of all the stories that were completed in the same sprint. The size can be measured in story points, hours, unit your team uses to estimate the work.

3. Quality Indicator: This metric shows the quality of the work done in a sprint. A lower defect density means fewer issues were found relative to the size of the work completed, indicating higher quality.

Example

Imagine your team completed stories with a total size of 100 story points in a sprint. Out of these, 10 defects were found. The Defect Density would be:

Defect Density=10 / 100 ​=0.1 or 10%

This means there were 10 defects for every 100 story points of work completed, helping to understand the quality of the work done during the sprint.

Trend

A 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 :

 Processor Fields

Mandatory fields

Project Settings

1. Navigate to Project Settings: Start by going to the Project Settings in your application.

2. Access the Mapping Section: Within Project Settings, find and click on the Mapping option.

3. Mandatory Field: In the Mapping section, you’ll find the Mandatory Field. This is where you’ll configure the necessary global mapping fields.

4. Configure the Fields:

Defect Mapping :

• Issue Type to identify Defect - all the issue type that signify defect

Issue type Mapping :

• Issue type for subtask Defect - Any specified issue category will be treated as a subtask that is linked to a story.`

Mandatory fields

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.

1. Ensure Defects are Tagged to Stories:

   • Mandatory: All defects must be linked to user stories. since unlinked defects will not be considered

   • Sprint Closure: Ensure that these stories are closed within the same sprint.

2. Include/Exclude Rejected, Dropped, or Abandoned Defects/Stories:

   • Include: If you want to include these defects/stories in your validation, ensure they are part of your JQL query.

   • Exclude: If you want to exclude them, modify your JQL query accordingly.

3. The issues identified as stories and defects should belong to the sprints of the configured project scrum board

4. Verify the sprint snapshots of closed sprints

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

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.