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

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.

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

      

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 is desirable

Maturity Levels

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

Set the desired first-time pass rate threshold

Configurations

Processor Fields

NA

Mandatory fields

• Issue type Mapping

  • Issue types to consider ‘Completed status eg; Story, Tech Story

• Workflow Status Mapping

  • Status to identify completed issues eg; Closed ,Resolved,, Done , Live

• Status for 'In Development' issues eg; Analysis, In Progress

• Status to Identify In Testing Status

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.