Iteration dashboard has been designed to assist the Scrum team in viewing information that can help them in identifying progress, delays and the intervention required to meet the Iteration goal
Some of this information is also available in agile project management tools like Jira and Azure boards, but KnowHOW helps you view everything in one single view
Team that includes Scrum Master, Developers, QE, Product owner can make use of this dashboard on a daily basis. It should be referred to in the daily standups as well the retrospective meetings to bring in agility to the ways of working.
A PSknowHOW user, based on their convenience and usability of Iteration KPI’s can choose to drag and drop them across the Iteration board and rearrange as per the need and save it by clicking 'Save Dashboard View' button.
Iteration dashboard has 2 filters
Project
Sprint
By default the project that comes first in alphabetical order and with atleast one Iteration is shown first.
Based on the selected Iteration, user sees
Start date & End date of the Iteration
Days left in the Iteration
Shows number of days remaining in the selected sprint
Sprint End Date - Current date (include the current day), Exclude Saturday and Sunday
Capacity of the Iteration (In Hours)
Capacity is defined for each Iteration under the Capacity tab in admin section of KnowHOW
Capacity can be defined for the complete team
Capacity can be defined for each individual and the tools sums it for the team
If the capacity is not defined, it is seen as 'N/A'
Predicted completion date : Predicted completion date (PCD) is calculated for an issue after factoring in all the work (issues) assigned to an individual, the issue with earliest due date and each issues corresponding remaining estimate. Assumption is that 'In Progress' issues are being worked upon so first the PCD by adding remaining estimate to todays date and similarity the PCD's are calculated for other In Progress and Open issues.
ℹ
| Table of Contents |
|---|
...
KPI Name
...
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.
A date field that highlights when a story ideally needs to be completed based on iteration planning
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
...
Issue ID
Issue Type
Priority
Description
Status
Due Date
Remaining Estimate
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,
Map all ‘In Progress status’ in mappings for your project
Ensure Original Estimate is added to all issues in a sprint
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
...
| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
KPI Definitions
KPI Name | Definition | Calculation logic | Filters | Overlay Screen |
|---|---|---|---|---|
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
| Filter by issue type Filter by Status |
|
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 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 |
|
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 |
|
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. |
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,
Update Due date on each issue
Update remaining estimate on each issue
Ensure issues are assigned to the correct person.
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 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* -
** - the delay in all the stories will be calculated from sprint end date + remaining estimate | 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
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
Original Estimates - Derived from Actual Estimate field in Jira
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
Issue type (Multi-select)
Priority (Multi-select)
Both work in combination
ℹ
Estimate vs Actual
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 |
|
Status
Original Estimate
|
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
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
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
|
|
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
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 |
Note:
| 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:
| ||
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. |
| Filter by priority Filter by issue type |
|
|
Issue Priority
|
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
Scope added
Scope Removed
User should see each of the information based on 3 parameters
Issue count
Story Points
The Widget should have 2 multi-select filters
Issue type
Issue status
Issue ID
Issue Type
Description
Status
Daily Closures
| ||||
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 |
|
Estimation Hygiene
Combination of
Stories without estimation
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
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
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 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
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.
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
Issue ID
Issue Type
Description
Size
Blocked time
Wait time
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:
Linked defects to story
Defect Injection Rate
Defect Density
Unlinked defects
*Any defect created during the iteration duration but is not added to the iteration is not considered
Linked defects to story - All defects raised that are linked to stories tagged to the Sprint. These defects should have been created between the start and end date of the duration.
Defect Density - Defects considered as per logic of Pt.1 / Sum of the size of stories that have linked defects
Unlinked Defects - All defects added to the Sprint and not tagged to a story (post sprint start)
Defects with following scenarios will not be shown on this
Defects created during an Iteration but not added to it
Real-time data refresh
Users can see real-time data for the active sprint by clicking the Refresh CTA. When a user clicks on Refresh, he is asked for a confirmation. Upon confirmation, data fetch gets initiated and it takes up to 30 sec for the dashboard to be refreshed with the latest updates in Jira/Azure tool. While refresh is in progress, the ‘Refresh’ CTA changes to ‘Syncing’. When the sync is finished, the last updated date gets refreshed.
This functionality allows to review that latest KPI information
...
Azure Boards Implementation Explained
Required Configuration Field Mapping - Iteration Dashboard & SPEED KPIs Completion Status - identify completed issues in the sprint report.
Based on field mapping divide into completed and not completed issues for sprint report
when configuring Azure project and the first initial run saved that time of snapshot for closed sprint data, after that closed sprint details data will not change.
For Active sprint, Compare saveddbTotalIssues and fetchedTotalIssues , if any new issues found then it will be consider as added issues, and if any issues is missing then it will be considered as punted issues.
and every run it will compare issues and maintain a snapshot of the sprint and after the closed sprint it will be saved the last day snapshot of the sprint.
for future sprint data will be only saved for first time after that it will be data will be updated when that particular sprint will be active.
Limitation to Azure Boards implementation for snapshot KPIs
if any user delete data of the project , impact lost all snapshot sprint details after the next run fetch data based on the latest data.
If a user added any issues type from field mapping ( Issue Types to be fetched from Jira) then sprint report data will be mismatched . for example closed sprint snapshot will be not change. new issues type will be not shown in closed sprint report and for active sprint all new issues will be counted as added issues in the sprint report .
In case of last day active sprint between the sprint closed time , it will be any changes and did not run processors then may be some delta data will be missing for not completed issues.