Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

KPI Name

Definition (info)

Calculation logic

Filters

Overlay Screen

Iteration Status

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.

  1. A date field that highlights when a story ideally needs to be completed based on iteration planning

  2. Remaining estimate that is calculated once users log work

*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

  1. Issue ID

  2. Issue Type

  3. Priority

  4. Description

  5. Status

  6. Due Date

  7. Remaining Estimate

  8. Delay

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.

For the KPI to reflect meaningful info,

  1. Map all ‘In Progress status’ in mappings for your project

  2. Ensure Original Estimate is added to all issues in a sprint

  3. Assignees should be kept up to date in Jira

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

  1. Issue ID

  2. Issue Description

  3. Issue Status

  4. Issue Type

  5. Size (Story Point/Hours)

  6. Original Estimate

  7. Due Date

  8. Actual Completion date

  9. Delay

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,

  1. Update Due date on each issue

  2. Update remaining estimate on each issue

  3. Ensure issues are assigned to the correct person.

  4. For any stories spilled, update the due date so that is falls between the active iteration

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

  1. Issue ID

  2. Issue Description

  3. Issue Status

  4. Issue Type

  5. Size (Story Point/Hours)

  6. Original Estimate

  7. Remaining Days

  8. Due Date

  9. Predicted completion date

  10. Potential delay (in days)

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

  1. Original Estimates - Derived from Actual Estimate field in Jira

  2. Logged Work - Logged work field in Jira 

The above information should be summed up for all issues in the selected sprint

This KPI can be filtered based on

  1. Issue type (Multi-select)

  2. Priority (Multi-select)

Both work in combination

  • Estimate vs Actual

  1. Issue ID

  2. Issue Type

  3. Description

  4. Status

  5. Original Estimate

  6. Logged work

Closures possible today

  • Closures possible today gives intelligence to users about how many issues can be completed on a particular day of an iteration. An issue is included as a possible closure based on the calculation of Predicted completion date.

Source of KPI is Jira and KnowHOW

This widget should show Closures possible on a day based on

  1. Issue count

  2. Story Points

One multi-select filter of issue type

Logic to calculate is

  • Either an issue is 'In Testing' status. This is based on 'Status to Identify In Testing Status' under configuration

OR

  • The remaining estimate is <=8 hours

  • Issue ID

  • Issue Type

  • Issue Description

  • Size (Story Point/Days)

  • Issue Status 

  • Due Date

  • Remaining Estimate

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

  • Issue ID

  • Issue Type

  • Issue Description

  • Issue Priority

  • Size (Story Point/Days)

  • Issue Status 

  • Due Date

  • Remaining Estimate

  • Predicted Completion Date

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

  1. Scope added

  2. Scope Removed

User should see each of the information based on 3 parameters

  1. Issue count

  2. Story Points

The Widget should have 2 multi-select filters

  1. Issue type

  2. Issue status

  1. Issue ID

  2. Issue Type

  3. Description

  4. Status

Daily Closures

Daily Closures KPI gives a graphical representation of no. of issues closed planned to be closed each day of iteration, actual count of issues closed day wise 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

  1. Issue ID

  2. Issue Type

  3. Description

  4. Status

  5. Size

  6. Due Date

  7. Remaining Estimate

  8. Potential Delay

  9. Predicted Completion Date

Estimation Hygiene

Combination of 

  1. Stories without estimation

  2. Missing worklogs

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 

  1. Issues with Estimates

  2. Issues without Estimates

One Multi-select Dropdown to filter by issue type

Legend has to be changed to 

  1. Issues with Worklogs

  2. Issues without Issues without Worklogs

Remove

Stories without estimates

Missing 

  1. Issue ID

  2. Issue Type

  3. Description

  4. Status

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.

  • Two configuration fields need to be added under Workflow Status mapping under Jira mappings

    • ‘Wastage - Blocked Status’

      • The statuses that signify that team is unable to proceed on an issue due to internal or external dependency like On Hold, Waiting for user response, Blocked etc should be included. 

    • ‘Wastage - Wait Status’

      • The statuses wherein no activity takes place and signify that the issues needs to move to picked up by a team member like Ready for deployment, Ready for testing etc

  • Saturday and Sunday are included in calculation of Blocked time and Wait time

Filter by priority

Filter by issue type

  1. Issue ID

  2. Issue Type

  3. Description

  4. Size

  5. Blocked time

  6. Wait time

  7. Total wastage

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:

  1. Linked defects to story

  2. Defect Injection Rate

  3. Defect Density

  4. Unlinked defects

*Any defect created during the iteration duration but is not added to the iteration is not considered