Versions Compared

Old Version 4

changes.mady.by.user Mamatha Paccha

Saved on

compared with

New Version Current

changes.mady.by.user Pranav Barar (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
maxLevel6
minLevel1
outlinefalse
typelist
printablefalse

Anything that is marked RED, is part of Backlog

Story

KPI Name / Definition

Representation

Tool

Maturity Levels

KPI Calculation

On Hover

Remarks

Status

Line Graph

Issue Count

measures the overall work taken in a sprint

Line Graph

  • Y- Axis - Count

  • X- Axis - Sprints

  • Aggregation Method - Sum

  • Positive trend indication - N/A

Agile Project Management

  • Jira

  • Azure

No Maturity Trend

It is calculated as No. of stories tagged to a Sprint

Sprint Name: <<Value>>

  1. ‘Story count issue type’ is used to identify issues that are considered for Story count issue type

  2. Issues defined in the configuration filter our the from the issues mentioned in the Sprint Report (Completed and Not Completed category)

Sprint Velocity

measures the rate at which a team can deliver every Sprint.

Since a stable velocity helps in forecasting, the KPI also measures the last 5 sprints average velocity and plots it along with the sprint velocity

Line Graph

  • Y- Axis - Count

  • X- Axis - Sprints

  • Aggregation Method - Sum

  • Positive trend indication - N/A

Agile Project Management

  • Jira

  • Azure

No Maturity Trend

SPRINT VELOCITY calculated as Sum of story points of all stories completed within a Sprint

Last 5 sprints

Sprint Name: <<Value>>

  1. This KPI calculation is based on the total story points of all issues from the completed issues in the Sprint Report

  2. If estimation is configured as Original Estimation for the board, then calculation is based on the total original estimate of all issues from the completed issues in the Sprint Report (Total hours will be converted to story points, i.e., 8 hrs = 1sp)

Sprint Capacity Utilization

depicts the maximum amount of time a team can commit within sprint

Line Graph + Column chart

  • Y- Axis - Hours

  • X- Axis - Sprints

  • Aggregation Method - Sum

  • Positive trend indication - N/A

Agile Project Management

  • Jira

  • Azure

No Maturity Trend

SPRINT CAPACITY UTILIZATION

This KPI is calculated based on 2 parameters

Estimated Hours: It explains the total hours required to complete Sprint backlog. The capacity is defined in KnowHOW

Logged Work: The amount of time team has logged within a Sprint. It is derived as sum of all logged work against issues tagged to a Sprint in Jira

Sprint Name:  <<Value>>

Sprint Predictability

Average Resolution time

measures average time taken to complete an issue that could be a story or bug etc.

Commitment Reliability

measures the percentage work completed at the end of a sprint in comparison to the total work in the sprint

Line Graph 

  • Y- Axis -

Days

  • Percentage

  • X- Axis - Sprints

  • Aggregation Method - Average

  • Positive trend indication -

Decrease

  • Increase

Agile Project Management

  • Jira

  • Azure

M1

: => 10 days

- <40%

M2

: 8-10 days

- 40-60%

M3

: 5-8 days

- 60-75%

M4

: 3-5 days

- 75% - 90% , 

M5

: <= 3 daysSum of resolution times of all issues completed in the Sprint/No. of issues completed within a sprint

- > 90%

It is calculated No. of issues or Size of issues completed/No. of issues or Size of issues committed

  • It is calculated as a

‘Days’

  • 'Percentage'.

Fewer the days better is the ‘Speed’

  • Higher the percentage during a sprint, better forecasting can be done for future sprints

  • Maturity of the KPI is calculated based on the average of last 5 values that corresponds with the maturity scale

*If the KPI data is not available for last 5 sprints, the Maturity level will not be shown

Sprint Name: <<Value>>

Overall filter option is configurable at the instance level

Number of Check-ins & Merge requests 

helps in measuring the transparency as well the how well the tasks have been broken down. 

Line Graph

  • Y- Axis - Count 

  • X- Axis - Days

    • Aggregation Method - Sum'

    Date: <<Value>>

    Mean time to merge

    measures the efficiency of the code review process in a a team

    Line Graph

    Sprint Name: <<Percentage Value>>

    Delivered: <<Count/Size>>

    Committed: <<Count/Size>>

    1. Users can ‘Filter by Issue type’. Upon selection of an issue type from the filter, the trend graph shows the commitment reliability for selected issue type

    2. Another filter allows the user to see the delivered percentage w.r.t either

      1. Initial commitment based on Issue count

      2. Initial commitment based on Story Points

      3. Final Scope based on Issue Count

      4. Final Scope based on Story Points

    Sprint Predictability

    Measures the percentage the iteration velocity against the average velocity of last 3 iteration.

    Line Graph 

    • Y- Axis - Percentage

    • X- Axis - Sprints

    • Aggregation Method - Average

    • Positive trend indication - Increase

    Agile Project Management

    • Jira

    • Repos

    M1: 0-2

    M2: 2-4

    M3: 4-8

    M4: 8-16

    M5: >16

    NUMBER OF MERGE REQUESTS when looked at along with commits highlights the efficiency of the review process

    • It is calculated as a Count. Higher the count better is the ‘Speed’

    • Maturity of the KPI is calculated based on the latest value

    • Azure

    M5 - 95% -105%
    M4 - 85-95%, 105-115%
    M3 - 75-85%, 115-125%
    M2 - 60-75%, 125-140%
    M1 - <60%, >140%

    It is calculated as

    sprint velocity of the targeted sprint/average sprint velocity of previous 3 sprints

    Sprint Name: <<Percentage Value>>

    Sprint Capacity Utilization

    explains the effectiveness of sprint planning and sprint execution.

    Line Graph + Column chart

    • Y- Axis - Hours

    • X- Axis -

    Weeks

    • Sprints

    • Aggregation Method -

    Average

    • Sum

    • Positive trend indication -

    Decrease

    • N/A

    Agile Project Management

    Repos

    • Jira

    • Azure

    M1:

    > 48 Hours

    <20%

    M2:

    16

    20-

    48 Hours

    40%,

    M3:

    8

    40-

    16 Hours

    60%,

    M4:

    4

    60-

    8 Hours

    80%,

     

    M5:

    <4 Hours

    • It is calculated in ‘Hours’. Fewer the Hours better is the ‘Speed’

    • Maturity of the KPI is calculated based on the average of last 5 values that corresponds with the maturity scale

    Date Range: <<Hours>

    Code Build Time 

    measures the time a job takes to build the code. 

    >80%

    SPRINT CAPACITY UTILIZATION

    This KPI is calculated based on 3 parameters and showcases 2 views

    Available Capacity: It depicts the total hours available for the Sprint . The capacity can defined in KnowHOW. Refer to Capacity Management

    Estimated Hours: Sum of the estimation of all issues taken in the sprint is considered as Estimated hours

    Logged Hours: The amount of time team has logged within a Sprint. It is derived as sum of all logged work against issues tagged to a Sprint in Jira

    Sprint Name:  <<Value>>

    1. Logged work will be represented by line graph whereas Estimated hours are represented by bar graph

    2. Estimated hours can be manually entered by users from the Capacity screen in KnowHOW (Settings-->Upload Data-->Capacity)

    3. An additional configuration allows to exclude spilled issues from Estimated Hours and Logged Hours calculation

    4. Enhanced to include the Original Estimate added in subtasks when calculating the estimation for the main story. (Release 8.0.0)

    Scope Churn

    Scope churn explains the change in the scope of sprint since the start of iteration

    Line Graph

    • Y- Axis -

    Min

    • Percentage

    • X- Axis -

    Weeks

    • Sprints

    • Aggregation Method - Average

    • Positive trend indication - Decrease

    Agile Project Management

    Jenkins

    • Jira

  • Bamboo

    • Azure

    M1:

    > 45 min

    >50%

    M2: 30-

    45 mins

    50%

    M3:

    15

    20-

    30 min

    30%

    M4:

    5-15 min, 

    10-20%

    M5:

    <5 min

    • It is calculated in  ‘Mins’. Lesser the time better is the ‘Speed’

    • Maturity of the KPI is calculated based on the average of last 5 values that corresponds with the maturity scale

    Date Range: <<min>>

    Lead Time

    is the time from the moment when the request was made by a client and placed on a board to when all work on this item is completed and the request was delivered to the client

    Visualization: Text + Table

  • Y- Axis - Percentage

  • X- Axis - N/A

  • Aggregation Method - Average

    • Positive trend indication - Decrease

    Commitment Reliability

    measures the percentage work completed at the end of a sprint in comparison to the total work in the sprint

    Line Graph 

  • Y- Axis - Percentage

    • X- Axis - Sprints

    <10%

    Scope Churn = (Stories added + Stories removed) / Count of Stories in Initial Commitment at the time of Sprint start 

    Sprint Name:  <<Value>>

    1. Issue type to identify story 

    Planning Accuracy

    measures if the team is planning iterations based on either capacity or the historical velocity.

    Line Graph

    • Y- Axis - Story Points/Hrs

    • X- Axis - Sprints

    • Aggregation Method - Sum

    • Positive trend indication - Difference

    Agile Project Management

    • Jira

    • Azure

    Lead time

    M1 : > 60 days

    M2 : 45-60 days

    M3 : 30-45 days

    M4 : 10-30 days, 

    M5 : <10 days

    Intake to DOR

    M1 : > 30 days

    M2 : 20-30 days

    M3 : 10-20 days

    M4 : 5-10 days, 

    M5 : < 5 days

    DOR to DOD

    M1 : > 20 days

    M2 : 10-20 days

    M3 : 7-10 days

    M4 : 3-7 days, 

    M5 : < 3 days

    DOD to Live

    M1 : > 30 days

    M2 : 15-30 days

    M3 : 5-15 days

    M4 : 2-5 days, 

    M5 : <2 day

    It is calculated as the sum of Ideation time, Development time & Release time

    Ideation time (Intake to DOR): Time taken from issue creation to it being ready for Sprint

    Development time (DOR to DOD): Time taken from start of work on an issue to it being completed in the Sprint as per DOD

    Release time (DOD to Live): Time taken between story completion to it going live.

    • Each of the KPIs are calculated in 'Days' . Lower the time, better is the speed & efficiency of that phase

    Sprint Name: <<Days>>

    M5 - 95% -105%
    M4 - 85-95%, 105-115%
    M3 - 75-85%, 115-125%
    M2 - 60-75%, 125-140%
    M1 - <60%, >140%

    Based on Average Velocity

    Planned work in SP/Average Velocity

    Based on Planned Capacity

    Planned work/Available Capacity

    Sprint

    Average Velocity/Planned Capacity - 50 SP or100 Hrs

    Planned work - 50 SP or100 Hrs

    Under configuration, user gets to select through a radio button

    1. Based on Average Velocity

    2. Based on Planned Capacity

    Code Build Time 

    measures the time a job takes to build the code. 

    Line Graph

    • Y- Axis - Min

    • X- Axis - Weeks

    • Aggregation Method - Average

    • Positive trend indication -

    Increase

    • Decrease

    Agile Project Management

    Jira

    • Jenkins

    • Bamboo

    • Azure

    M1

    - <40%

    : > 45 min

    M2

    - 40-60%

    : 30-45 mins

    M3

    - 60-75%

    : 15-30 min

    M4

    - 75% - 90%

    : 5-15 min, 

    M5

    - > 90%

    : <5 min

    • It is calculated

    No. of issues or Size of issues completed/No. of issues or Size of issues committedIt is calculated as a 'Percentage'. Higher the percentage during a sprint, better forecasting can be done for future sprintsCommitted: <<Count/Size>>

    • in  ‘Mins’. Lesser the time better is the ‘Speed’

    • Maturity of the KPI is calculated based on the average of last 5 values that corresponds with the maturity scale

    Sprint Name: <<Percentage Value>>

    Delivered: <<Count/Size>>

    Date Range: <<min>>