Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 33 Next »

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

  1. Project

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

  1. Start date & End date of the Iteration

  2. Days left in the Iteration

    1. Shows number of days remaining in the selected sprint

    2. Sprint End Date - Current date (include the current day), Exclude Saturday and Sunday

  3. Capacity of the Iteration (In Hours)

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

    2. If the capacity is not defined, it is seen as 'N/A'

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

ℹ

KPI Name

Definition (info)

Calculation logic

Filters

Overlay Screen

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

Scope of work is evaluated in terms of issue count/size of work in Story points (SP)

The widget should show

  1. Iteration Commitment

  2. Scope added

  3. Scope Removed

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

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

Completed work is based on the ‘Issues completed’ list in Sprint report in Jira

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

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

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

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

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

  • 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

  1. Defects created during an Iteration but not added to it

  2. Defects created during an iteration/added to iteration but tagged to a story part of some other iteration

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.

  • 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

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

  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

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

  • No labels

© 2022 Publicis Sapient. All rights reserved.