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 Chart | ||
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. Numerator:
ExampleImagine 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 | |||
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 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 | KPI Specific fields | NA | |
Mandatory fields | Project Settings
| ||
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" | ||
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 | How does the KPI help |
...
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. | |