First time pass rate (FTPR)

Applicability

Scrum-based projects

Definition (Hover Text)

Measures the percentage of tickets that pass QA the first time with no return transition in workflow or no defects linkages.
This metric reflects the efficiency and effectiveness of the development process, highlighting how often the team gets things right the first time.

Source Tools

Jira, Azure Boards

Graph type

Line Chart

Filters

<None>

Hover Format on KPI

Sprint Name: <<Percentage Value>>

FTP Stories: <<Value>>

Closed stories: <<Value>>

Fields on Explore

1. Sprint Name

2. Story ID

3. Issue Description

4. First Time Pass

5. Defect IDs

6. Defect description

7. Defect priority

8. Defect status

9. Time spent

Business Logic

Calculation Formula

No. of issues closed in a sprint which do not have a return transition or any defects tagged/ Total no. of issues closed in the iteration.

Numerator:

• This is the count of issues that were completed in a sprint and didn’t need to be reopened or fixed again. Essentially, these issues passed Quality Assurance (QA) on the first try without any defects.

Denominator:

• This is the total count of issues that were completed in the same sprint, whether they needed rework or not.

Example

Imagine your team closed 50 issues in a sprint. Out of these, 40 issues were closed without needing any rework or fixes. The FTPR would be:

FTPR=50/40 ​=0.8 or 80%

This means 80% of the issues were done correctly the first time, which is a good indicator of the team’s performance.

KPI Settings

1. Issue types mapping

   1. Primary → ‘Issue types filter for completed issues'

   2. Secondary → 'Labels to filter issues in consideration' can be used to filter the desired set of issues considered in the primary setting

      Open

      

2. Defects field mappings

   Open

   

3. Workflow Status field mappings

   1. Status to identify rejected defects

   2. Status to identify issues that did not achieve a First Time Pass *

   3. Status to identify issues in development & Status to identify issues in testing
      Issues with backward transition from ‘In Testing’ statuses to ‘In Development’ will fail the first-time pass criteria.
      *Please note:- these statuses do not apply if the ‘Status to identify issues that did not achieve a First Time Pass’ field is set

   4. Resolution type to be excluded : resolution types for defects that can be excluded

   5. Status to identify completed issues

      Open

      

*Please note:- Global mappings and default Jira statuses of sprint reports will apply if the KPI level settings are not used.

Trend

An upward trend in FTPR indicates improving quality and efficiency.

Maturity Levels

FTPR Maturity is assessed by averaging data from the last 5 sprints. This helps in understanding the stability and improvement over time.

M1: <60%
M2: 60-79%
M3: 80-89%
M4: 90-94%
M5: >=95%

*Please note:- KPI widget denotes the average maturity over data points

Target KPI Value

Target KPI Value denotes the bare minimum a project should maintain for a KPI.

Global Configurations (Field Mapping)

Processor Fields

NA

Mandatory fields

Project Settings

1. Navigate to Jira/ Azure Board Settings: Go to Settings → Projects → Edit Config → Mappings

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

3. Configure the Fields.

• Sprint Name: Provide the custom field that is linked with the Sprint.

Open

How to Validate KPI

Suggested ways of working

1. Configure a standardized set of issue types and workflow statuses in the field mappings for your project

2. Avoid frequent changes to the settings as that may affect the trend

3. Verify the sprint snapshots of closed sprints

Sample JQLs

basic JQL query to get the issues completed in a sprint: project = "Your Project Name" AND Sprint in closedSprints() AND status in (Done, Closed)

JQL query to get the issues that were completed without needing to be re-opened: : project = "Your Project Name" AND Sprint in closedSprints() AND status in (Done, Closed) AND NOT status changed AFTER -1w TO "In Progress"

Best Practices

Define Clear Acceptance Criteria

Ensure that all user stories and tasks have well-defined and agreed-upon acceptance criteria to guide development and testing efforts.

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.

Perform Root Cause Analysis

Conduct root cause analysis for any defects that do occur to identify and address the underlying causes, preventing recurrence.

Benefits of KPI

Quality Assurance

A high FTPR indicates that the team consistently meets quality standards, reducing the need for rework and ensuring higher product quality.

Efficiency

By minimizing rework, the team can maintain a steady workflow, leading to faster delivery of features and more predictable sprint outcomes.

Cost Reduction

Reducing the number of defects and rework decreases the overall cost of development and maintenance.

Customer Satisfaction

Delivering high-quality features without the need for rework enhances customer satisfaction and trust.