ITERATION Dashboard

Iteration Commitment

Iteration commitment shows in terms of issue count 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

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

It shows count of the issues which 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 

Remaining work in the iteration in terms count of issues & sum of story estimates. Sum of remaining hours required to complete pending work.

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

It gives intelligence to the team about number of issues that could potentially not get completed during the iteration. Issues which have a Predicted Completion date > Sprint end date are 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.

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

It showcases the 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

The overlay window shows linked defects grouped for each story (Release 8.0.0)

First Time Pass Rate

Percentage of tickets that passed QA with no return transition or 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 = 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 Status

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.

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

It shows the count of issues which do not have estimates 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