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 Overlay

1. Sprint Name

2. Story ID

3. Issue Description

4. First Time Pass

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 to consider:

   1. Primary → ‘Issue types to consider 'Completed Status’

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

      Open

      
      Open

      

2. Defects field mappings

   1. Priority to be excluded

   2. Root cause values to be included

3. Workflow Status field mappings

   1. Status to identify completed issues

   2. Resolution type of defects to be excluded

   3. Status of defects to be excluded

   4. Status for ‘In development’ issues & Status for ‘In Testing’ issues
      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 ‘FTPR Rejection Status’ field is set

   5. FTPR rejection status : custom statuses can be used to identify failed issues.

*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 <25% 

M2 >=25-50% , 

M3 - >=50-75% , 

M4 - >=75-90%  , 

M5 - >=90%

*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

NA

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.

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

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.