Content Comparison

Iteration Commitment

Iteration 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. And finally the KPI shows the Overall commitment which is Initial committed adjusted with Scope changes.Scope of work is evaluated in terms of issue count /size of work in Story points (SP)and story points the Initial commitment (issues tagged when the iteration starts), Scope added and Scope removed.

The widget should show

1. Initial Commitment

2. Scope added

3. Scope Removed

• Initial Commitment widget will show the data of Issues completed + not completed + scope removed - scope added for the Iteration.

• Scope added widget will show the data added issues for the sprint - The issues with * symbol from sprint report.

• Scope removed widget will show the removed issues from the sprint - The issues from Scope removed collection from sprint report.

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. Priority

7. Due Date

8. Original Estimate

9. Remaining Estimate

10. Assignee

Planned Work Status

Planned work signifies that part of iteration backlog that was refined and sized by the team during iteration planning. In KnowHOW, if Due date is added to an issue it is considered as Planned work

Planned work status shows 3 elements of information

1. Planned completion - Issues that were planned to be completed in terms of issue count/story points

2. Actual completion - Issues that have been completed in actual in terms of issue count/story points

3. Delay - Overall delay in days after summing up the delay of issues completed

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

It shows count of the issues having a due date which are planned to be completed until today and how many of these issues have actually been completed. It also depicts the delay in completing the planned issues in terms of days.

Planned - Show only the ones with due date
Actual - Show amongst the ones having due date, which are completed.
Delay - Show in Days (similar to Work remaining) by adding Actual delay (delay of all planned issues) + Potential delay of all planned issues (maximum delay of each assignee) on overlay.

Actual Delay is calculated between due Date & completed Date of issue.

Potential Delay is calculated between due Date & Predicted Completed Date.

Filter by Issue type

Filter by Priority

1. Issue ID

2. Issue Description

3. Issue Status

4. Issue Type

5. Size (Story Point/Hours)

6. Remaining Estimate

7. Priority

8. Assignee

Unplanned Work Status

Unplanned Work Status keep track It shows count of the issues which doesn’t do not have a due date. It also shows the completed count amongst the unplanned issues.

Overall Unplanned - Show the issues which doesn’t have due date

Completed - Show amongst the ones which are not having due date and completed.

Filter by Issue type

Filter by Priority

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

10. Predicted Completion Date

11. Potential Delay

12. Assignee

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 count of issues & sum of story estimates. Sum 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

Potential Delay - Show in Days (sum of max. delay of each assignee)

Source of this KPI is Jira. To see the latest data, run the Jira processor from KnowHOW settings

The Delay of in progress stories was getting add up to subsequent stories, so we have changed the logic as per below

On Overlay we are showing delay of all the stories, but on kpi, calculation of only in progress stories are applied

In Active sprint

** - *(1)* {+}In progress stories{+}: the delay will be calculated as per today's date i.e., todays's date + remaining estimate, for all the stories marked as *in progress* -
** - {+}in Open stories{+}-the remaining stories are considered as open stories, sort open stories by due date. -
*** - the last PCD which we got from *(1)* will be used to calculate the pcd for open story as a starting point, -
*** - the subsequent story delay will be calculated from the last pcd of the open story -
*** - if 2 stories having same due date the one having maximum pcd will be used for further calculation{*}{{*}} -

• - *In closed sprint* -  

**   - the delay in all the stories will be calculated from sprint end date + remaining estimate

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)

Issues likely to spill

Issues likely to spill It 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 during the iteration. Issues which have a Predicted Completion date > Sprint end date for an issue, it is considered to be potential spillSource of this KPI is Jira. To see the latest data, run the Jira processor from KnowHOW settingsare considered.

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

Filter by Issue type

Filter by Priority

• Issue ID

• Issue Type

• Issue Description

• Issue Priority

• Size (Story Point/Days)

• Issue Status 

• Due Date

• Remaining Estimate

• Predicted Completion Date

Closures possible today

It 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

• If Predicted completion date is today for the issue then that issue will show up on KPI

• Issue ID

• Issue Type

• Issue Description

• Size (Story Point/Days)

• Issue Status 

• Due Date

• Remaining Estimate

Quality Status

Quality status as a KPI It 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. Story Linked Defects

2. Defect Injection Rate

3. Defect Density

4. Unlinked defects

count of defect linked to stories and count that are not linked to any story. The defect injection rate and defect density are shown to give a wholistic view of quality of ongoing iteration

• Linked defects to story - All defects raised that are linked to stories tagged to the Sprint.

• Defect Injection Rate - No.of defects that are linked to closed stories for the iteration / No. of closed stories for the iteration

• Defect Density - No.of defects that are linked to closed stories for the iteration / Sum of the size of closed stories for the iteration

• Unlinked Defects - All defects added to the Sprint and not tagged to a story (post sprint start)

Note:

1. If one defect is linked to two stories, then those two stories should be closed for DIR/DD calculation.

2. On overlay - all defects which are linked to stories (closed or in progress) will be shown and green marker will represent the defects which are linked to closed stories for the Iteration

First Time Pass Rate

First Time Pass Rate measures the percentage Percentage of tickets that pass QA first time (without stimulating a passed QA with no return transition or defect tagged)any tagging to a specific configured status and no linkage of a defect.

First Time Pass Stories - Stories which are not having return transition or defect tagged.

Total Stories - Complotted issues from sprint report.

First Time Pass Rate - First Time Pass Stories/Total Stories.

Note:

1. Issue types configured under Issue Type Mapping - FTPR will be considered as stories.

2. Exclusion parameters(defect priority, RCA) will work same like Quality board FTPR.

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 configured statuses or flagging of issues in Jira. For e.g. If On Hold status is configured as Blocked, that are considered 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 = Blocked time + Wait time , Blocked time - Total time when any issue is in a status like Blocked as defined in the configuration or if any issue is flagged., Wait time : Total time when any issue is in status similar to Ready for testing, ready for deployment as defined in the configuration 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 excluded 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

Defect count by RCA

It shows the breakup of all defects within an iteration by root cause identified.

Defect count by RCA gives graphical representation of no.of issues by Root cause RCAStatus

It shows the breakup of all defects within an iteration by status. User can view the total defects in the iteration as well as the defects created after iteration start.

Defect count by Priority

It shows the breakup of all defects within an iteration by priority. User can view the total defects in the iteration as well as the defects created after iteration start.

Iteration Burnup

Iteration Burnup KPI shows the cumulative actual progress against the overall scope of the iteration on a daily basis. For teams putting due dates at the beginning of iteration, the graph additionally shows the actual progress in comparison to the planning done and also predicts the probable progress for the remaining days of the iteration.

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. Planned Completion Date (Due Date)

7. Actual Completion Date

8. Remaining Estimate

9. Delay/Potential Delay

10. Predicted Completion Date

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

issues.

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

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 It shows the count of 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 settingsestimates and count of In progress issues without any work logs.

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