Purpose

Enable Train uses dashboards to visualise data from Jira to understand team trends.

This data is visualised per quarter (90 days, 7 iterations), and utilised in retrospectives and gemba walks. 

Template examples

There are two templates: Kanban or Scrum.

  1. The Scrum template shows data per sprint. Examples: SNESSparkle
  2. The Kanban template shows data per day, or where able per artificial 2-week interval. Examples: Cloud-Rangers, Engine, FrameworkersOnyx

Template categories

The dashboards follow the four metric categories defined by the Yamaha Project Management Office.

Flow

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.

Quality

Quality metrics are about the technical quality of our systems and software, and can be recognised by their purple border. Definition of Done should be stored in the linked location on Confluence.

Outcome

Outcome metrics are about business value realised and commuicated, and are not automated. You are expected to maintain these outside Jira.

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.

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


Output charts


Quality charts