Overview | |||
---|---|---|---|
Applicability | Scrum-based projects | ||
Definition (Hover Text) | measures Measures the percentage of tickets that pass QA first time (without stimulating a the first time with no return transition or not having a linked defect)in workflow or no defects linkages. | ||
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 |
| ||
Business Logic | |||
Calculation Formula | No. of issues closed in a iteration sprint which do not have a return transition or any defects tagged/ Total no. of issues closed in the iteration. | ||
KPI Settings |
| Trend | Positive trend indication - Increase*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 |
| ||
How to Validate KPI | |||
Suggested ways of working |
| ||
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" | ||
Benefits of KPI | |||
How does the KPI help | The First Time Pass Rate KPI measures the percentage of products or services that pass quality checks on the first attempt, reducing rework, improving customer satisfaction, increasing productivity, and identifying areas for improvement | ||
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. | ||
Page Comparison
General
Content
Integrations