...
KPI Name | Definition | Calculation logic | Filters | Overlay Screen | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Iteration StatusCommitment | Iteration Status explains the progress in terms of delay in number of days. It also shows number of issues that are delayed and number of issues that have been completed before time | The calculation logic is based on 2 main parameters.
*The accuracy of the KPI is dependent upon the correctness of information mentioned in tool like Jira/Azure | Filter by priority Filter by issue type |
| Work Completed | Work Completed KPI gives a depiction of completion status based on no. of issues and size of work (in SP). In addition, it also lets the user know the day wise delay for each issue that has been completed. The calculation consider issues of each individual in an iteration and then considers original estimate.commitment illustrates the scope of work committed by the team at the beginning of iteration. The KPI also shows the scope of work added and removed during the iteration Scope of work is evaluated in terms of issue count/size of work in Story points (SP) | The widget should show
| Filter by issue type Filter by Status |
| ||
Overall Completion Status | Overall completion status depicts the planned vs actual progress in terms of issue count and story points It also shows the delay (days) that has happened in the completed work For the KPI to reflect meaningful info,
Completed work is based on the ‘Issues completed’ list in Sprint report in Jira | Issue count - Total no. of issues that are completed. Story Points - Sum of story points of all issues that are completed | Filter by Issue type Filter by Status |
| |||||||
Work Remaining | Work Remaining KPI illustrates the remaining work in the iteration in terms of No. of Issues/ Size of Work (in SP) and in terms of Remaining Hours required to complete pending work. In addition, it also shows the potential delay because of all pending stories. Potential delay and predicted completion date can be seen for each issue as well For the KPI to reflect meaningful info,
Issues that show up in the KPI are based on the ‘Issues not completed’ list in Sprint report in Jira. | Issue count - Total no. of issues that are not completed. Story Points - Sum of story points of all issues not completed Hours - Sum of remaining hours of all incomplete issues in Jira Source of this KPI is Jira. To see the latest data, run the Jira processor from KnowHOW settings | Filter by Issue type Filter by Status |
| |||||||
Estimate vs Actual | Estimate vs Actual gives a comparative view of the sum of estimated hours of all issues in an iteration as against the total time spent on these issues Issues likely to spill | ]Issues likely to spill gives intelligence to the team about number of issues that could potentially not get completed. This prediction is based on the the Predicted Completion date i.e if Predicted completion completion date > Sprint end date for an issue, it is considered to be potential spill Source of this KPI is Jira fields - Original Estimate and Logged Work. To see the latest data, run the Jira processor from KnowHOW settings | Shows 2 data points
The above information should be summed up for all issues in the selected sprint This KPI can be filtered based on
Both work in combination ℹ
| Issue ID Issue Type Description Status Original Estimate This widget shows number of issues likely to spill. It is based on the logic of remaining estimate of an issue and comparing it with the remaining time in the sprint. 1 day considered as 8 hours |
| ||||||
Closures possible today |
Source of KPI is Jira and KnowHOW | This widget should show Closures possible on a day based on
One multi-select filter of issue type Logic to calculate is
OR
|
| Issues likely to spill | ]Issues likely to spill gives intelligence to the team about number of issues that could potentially not get completed. This prediction is based on the the Predicted Completion date i.e if Predicted completion completion date > Sprint end date for an issue, it is considered to be potential spill Source of this KPI is Jira. To see the latest data, run the Jira processor from KnowHOW settings | This widget shows number of issues likely to spill. It is based on the logic of remaining estimate of an issue and comparing it with the remaining time in the sprint. 1 day considered as 8 hours |
| Scope Changes | Scope change KPI highlights change in iteration scope since the start of iteration. It showcases added as well as removed issue count and the corresponding story points Source of this KPI is Jira. To see the latest data, run the Jira processor from KnowHOW settings | ||
The widget should show
User should see each of the information based on 3 parameters
The Widget should have 2 multi-select filters Issue type Quality Status | Quality status as a KPI showcases the basic defect related metric that helps distinguish between story related defects, defects arising out of regression and their correlation to the complexity of work taken in the iteration The KPI shows:
*Any defect created during the iteration duration but is not added to the iteration is not considered |
Defects with following scenarios will not be shown on this
| |||||||||
First Time Pass Rate | |||||||||||
Wastage | Wastage considers total time an issue was not being worked upon by anyone in the team after moving to in progress. This is calculated based on the statuses that a configured as either on hold status or in queue status. On hold status could be 'Blocked', and Wait status could be Ready for Testing, Ready for deployment etc. |
| Filter by priority Filter by issue type |
| |||||||
Defect count by RCA | |||||||||||
Daily Closures | Daily Closures KPI gives a graphical representation of daily progress in terms of no. of issues planned, actual no. of issues closed till the current day and the predicted daily closures for the remaining days of the iteration Source of this KPI is Jira. To see the latest data, run the Jira processor from KnowHOW settings | User should able to see count of issues closed daily broken by issue type Chart type - Clustered Column X-Axis - Days (Dates) Y-Axis - Count |
| ||||||||
Estimate vs Actual | Estimate vs Actual gives a comparative view of the sum of estimated hours of all issues in an iteration as against the total time spent on these issues Source of this KPI is Jira fields - Original Estimate and Logged Work To see the latest data, run the Jira processor from KnowHOW settings | Shows 2 data points
The above information should be summed up for all issues in the selected sprint This KPI can be filtered based on
Both work in combination ℹ
|
| ||||||||
Estimation HygieneCombination of
| Estimation Hygiene acts as an indicator to identify issues which are either not estimated and the issues which do not have logged work. *This is just to measure the hygiene of Jira usage by a team Source of this KPI is Jira. To see the latest data, run the Jira processor from KnowHOW settings | KPI to be renamed to 'Issues without Estimates' One Multi-select Dropdown to filter by issue type Legend has to be changed to
One Multi-select Dropdown to filter by issue type Legend has to be changed to
Remove Stories without estimates Missing |
Wastage | Wastage considers total time an issue was not being worked upon by anyone in the team after moving to in progress. This is calculated based on the statuses that a configured as either on hold status or in queue status. On hold status could be 'Blocked', and Wait status could be Ready for Testing, Ready for deployment etc. |
| Filter by priority Filter by issue type |
| Quality Status | Quality status as a KPI showcases the basic defect related metric that helps distinguish between story related defects, defects arising out of regression and their correlation to the complexity of work taken in the iteration The KPI shows:
*Any defect created during the iteration duration but is not added to the iteration is not considered |
Defects with following scenarios will not be shown on this
|
