Overview | ||||
---|---|---|---|---|
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. | |||
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 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 |
*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 | ||||
Benefits of KPI | How does the KPI help |
...
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. | |