Page History
...
Flow metrics are about being able to continue working, and can be recognised by their light blue border.
Output
Output metrics are about our efforts to complete work and can be recognised by their dark blue border. Team Happiness should be filled each quarter in the linked survey.
...
The Kanban template
Flow charts
The cumulative flow diagram is linked to a Kanban Board, and shows tickets progress through the statusses shown on that board over time.
Ideally, the tiles between New and Done are thin, showing that the team is able to focus.
The steeper the chart, the better, because that would show that tickets are closed quickly.
The WIP Run Chart is linked to a Kanban or Scrum board.
Ideally, the amount of tickets in progress simultaneously is low, showing that the team is able to focus.
A rising trend line means that the team is increasing their WIP and is a warning sign for the team.
The Cycle Time Trend breaks work done up into 2-week periods, and shows the average amount of days the tickets solved in that period took.
On the right hand top the average for the entire quarter is shown.
A rising trend line means that the team is increasingly taking longer on average to solve their tickets and is a warning sign for the team.
The Kanban Velocity breaks work done up into 2-week periods, and shows the amount of items solved within each period.
On the right hand top the average solved per two weeks over the entire quarter is shown.
A dropping trend line means that the team is steadily decreasing the amount of tickets they solve over time and is a warning sign for the team.
Output charts
Quality charts
The Scrum template
Flow charts
Output charts
...
The Backlog Readiness shows what the Definition of Ready is for open items in this team's backlog.
This is measured by counting the field "DoR" present on all YIS tickets. SD tickets will show in this graph as "None".
Ideally a team has all items in process at the stage "ready for sprint", and roughly an equal amount at "acceptance criteria defined" (ready for next period).
Output charts
The Stories Resolved per week shows all YIS issuetypes at story level that the team resolved, clubbed together per week.
The legend can be expanded by clicking the >.
The SD Tickets Resolved per week shows all SD issuetypes that the team resolved, clubbed together per week.
The Created Versus Resolved shows all tickets (YIS and SD together) that were created and resolved per week, cumulative.
'Cumulative' means that the last measurement shows the total number for the entire quarter.
Quality charts
The Bugs Resolved Per Week shows how many Bug issue types were created and resolved by your team.
Ideally a team has no open bugs. Try to resolve these as soon as possible.
The "Retrospective" Items Done Per Week shows any item with "Retrospective" in the summary that has been resolved in that period.
This allows teams who choose to store their retro items in Jira to visualise process improvements over time in an automated fashion.
The Average Age Chart for SD Tickets shows how old the service desk tickets in this team are on average.
For example:
A team has three SD tickets
One ticket is 1 day old
One ticket is 2 days old
One ticket is 297 days old
Then the average ticket age on that day is 100 days.
Ideally, a team has no SD tickets older than the Service Level Agreement allows, which is 15 days for Low priority items.
The SD Tickets Remaining, Oldest First shows the fastest way to reduce average age of SD tickets: by resolving the top item.
Ideally, a team has no SD tickets older than the Service Level Agreement allows, which is 15 days for Low priority items.
The Priority is listed in the chart's second column.
The Scrum template
Flow charts
We are in search of a gadget that can show the Sprint Velocity chart on this dashboard. In the meantime, you can take the information from the following two charts:
The Story Points Delivered per sprint shows easy numbers on top of each bar, and allows you to navigate to the data with a single click.
The Team Velocity Chart shows the planned versus delivered, plus a trendline of (delivered / planned) in percentage.
The Sprint Burndown shows the progress within current sprint.
The blue line is the ideal burndown, showing how many story points or items should be completed per day to have a gradual pacing.
The orange line is the real burndown, going down once items are resolved.
Ideally, the two lines have the same starting point. If the blue line starts higher, that means that items were added to sprint after sprint start.
The WIP Run Chart is linked to a Kanban or Scrum board.
Ideally, the amount of tickets in progress simultaneously is low, showing that the team is able to focus.
A rising trend line means that the team is increasing their WIP and is a warning sign for the team.
The Backlog Readiness shows what the Definition of Ready is for open items in this team's backlog.
This is measured by counting the field "DoR" present on all YIS tickets. SD tickets will show in this graph as "None".
Ideally a team has all items in process at the stage "ready for sprint", and roughly an equal amount at "acceptance criteria defined" (ready for next period).
Output charts
The Stories Resolved per sprint shows all YIS issuetypes at story level that the team resolved.
The legend can be expanded by clicking the >.
The SD Tickets Resolved per week shows all SD issuetypes that the team resolved.
The Created Versus Resolved shows all tickets (YIS and SD together) that were created and resolved per week, cumulative.
'Cumulative' means that the last measurement shows the total number for the entire quarter.
Quality charts
The Bugs Resolved Per Week shows how many Bug issue types were resolved by your team.
Ideally a team has no open bugs. Try to resolve these as soon as possible.
The "Retrospective" Items Done Per Week shows any item with "Retrospective" in the summary that has been resolved in that period.
This allows teams who choose to store their retro items in Jira to visualise process improvements over time in an automated fashion.
The Average Age Chart for SD Tickets shows how old the service desk tickets in this team are on average.
For example:
A team has three SD tickets
One ticket is 1 day old
One ticket is 2 days old
One ticket is 297 days old
Then the average ticket age on that day is 100 days.
Ideally, a team has no SD tickets older than the Service Level Agreement allows, which is 15 days for Low priority items.
The SD Tickets Remaining, Oldest First shows the fastest way to reduce average age of SD tickets: by resolving the top item.
Ideally, a team has no SD tickets older than the Service Level Agreement allows, which is 15 days for Low priority items.
The Priority is listed in the chart's second column.
Overview
Content Tools