1. Dashboard
The Dashboard page provides insights on any issues at Backlog level (Story, Task, Bug, etc.). It excludes any levels higher such as Epic. Subtask issue type is not included in the dataset.
Productivity is measured as the number of completed issues (Stories, Tasks, Bugs) per week. This is commonly referred to as Throughput. The chart counts how many issues were finished each calendar week, as well as plotting the trend over time.
Any time an issue moves into past our ‘completed’ line it is included in our Throughput count.
The intention is to help teams find what level of throughput per week is consistently achievable and to find ways to increase this over time by improving their processes.
When overdriven, it can lead to your Quality metric going up (the wrong direction!) as more bugs are reported. Sustainability may also move down into more orange bars (starting more than finishing).
Throughput can be gamed by breaking down issues into smaller pieces (may not be a bad thing – so long as they are vertically slicing!). Teams could also prematurely sign-off work only to have bugs reported later (seen by increase in defect percentage in quality chart).
Quality is measured as the percentage of Throughput (completed work) that is a Bug issue type.
To calculate it, the number of Bugs completed each week is divided by the total count of completed issues that same week (with the result expressed as a percentage). For example, if you completed 4 Bugs and 6 Stories in a week, then your Quality measure for that week would be 40%.
The intention is to help teams continuously triage and complete bug issue types at a consistent rate. Try and drive to keep the percentage level (and low!) without deferring bugs.
When overdriven, your Responsiveness metric may increase for bug issue types. The number of open defects may grow (and thus work item age for these issues will increase) if Story work is done in preference.
It is gamed by entering Bugs as Stories - which may seen by growing Throughput, but lowering customer satisfaction and complaints.
Responsiveness is measured as the average cycle time (the blue line) for all items completed in the same week. Cycle time is calculated in calendar days, not working days. Error bars are added for the upper (90th percentile) and lower (10th percentile) cycle times for a given week. Use the drill through to see the breakdown for each individual item.
Cycle Time is the time (in calendar days) taken from when an issue first moves past our ‘Start’ line and over our ‘Completed’ line.
The intention is to help teams understand the cycle time for completing issues, and to look for ways to reduce the time (and variability) by eliminating unnecessary steps and waste.
When overdriven, your Quality metric goes up as more bugs are reported due to premature completion. Sustainability chart has higher peaks as more work completes but then work starts on more bugs that are opened.
It is gamed by only starting fast, simple work (seen by initial increasing Productivity only to regress later) and/or premature completion of issues (seen by growing Quality (Bug Rate) percentage).
Sustainability is measured as net flow per week. The chart counts how many issues were finished and subtracts how many issues were started for the same calendar week, creating a positive bar (blue) if more is finished than started, or a negative bar (orange) if more issues were started than finished.
Any time an issue moves past our ‘Start’ line (i.e. goes 'In Progress') it is included in our Started count. Any time an issue moves past our ‘Completed’ it is included in our Completed count.
Stop starting, start finishing! Help teams focus on finishing something in-progress (or helping someone on the team finish something) before starting something new. Aim for getting close to zero consistently (meaning we finish as many things as we start).
When overdriven, it can lead to your Quality metric going up (the wrong direction!) as more bugs are reported.
Throughput can be gamed as teams can prematurely sign-off work only to have bugs reported later (seen by increase in Quality (Bug Rate) chart). Teams can also slow down starting new work (seen by a decrease in Productivity (Throughput) chart).