Delivery reports use five metrics to help you manage workflow and efficiency: cycle time, queue time, backflow, jitter, and heat. In this article, we will go over the details of these metrics and show you how they correspond to delivery configurations. Learn more about delivery configurations.
Delivery Reports Metrics
Cycle time is the time between when a ticket enters an Active status, to the final Done status in its life cycle. Cycle time is only calculated when the ticket is currently in a Done status. Any tickets that are currently in a status marked as Not started or Active, will not have a cycle time calculated for them. Cycle time updates when tickets move backward from a done state.
Use cycle time to determine how long a ticket took to complete. Cycle time only captures the time actively worked on the ticket. It does not include lead time where product managers, designers, or stake holders provided requirements before the ticket entered an Active state.
In the screenshot above, you can see the ticket was in an active state. When the ticket was completed, it was moved to the done column and marked Done. Cycle time for this ticket started when it was in progress. Cycle time ended when it was marked done.
Queue time is the total time a ticket is in a waiting state. The engineer working on the ticket may need to wait for feedback, QA, or review from team members. Queue time captures these moments in the ticket life cycle.
As you set delivery configurations, you will be able to toggle a particular status as waiting as seen below.
Queue time is a representation of the total amount of time a ticket is in a waiting state. A queue time of 0h means the ticket has never been in a waiting status. Once the ticket enters a waiting status, queue time will start to accrue.
Backflow rate is the percentage of status transitions that move a ticket backwards. A high backflow rate indicates the ticket went through multiple reviews and modifications before it was complete.
Backflow rate is calculated as:
Backflow rate = Backflow transitions / Total transitions
A transition occurs when a ticket moves from one column to another. A transition across multiple columns at a single time only counts as a single transition for that ticket. For example, moving from Backlog to In Progress, would only represent one transition for that ticket. A status change within the column is not a transition.
A backflow transition occurs when a ticket moves back to a previous column.
In the screenshot below, you will see an example of backflow. Each number represents a transition.
As work on this ticket progressed, it moved forward from Backlog to Ready, In progress, and Testing columns.
The ticket then moved from the Out for review status, to the Pending QA status in the projects workflow. Because these two statuses are mapped to the same column, this does not count as a transition.
Then the ticket moved from the Testing column back to the In progress column. The movement from Testing to In progress is an example of a backflow transition.
For this ticket, there were four total transitions. There was one backflow transition .
So we get, Backflow = Backflow transitions / Total transitions = ¼ = 25%
Heat is a configurable, time-specific measure of current ticket activity. Heat occurs in all ticket states. Heat decays over time. This means a ticket that is “hot” today will not be “hot” next month unless there is continued activity on that ticket.
Activity such as comments, body modification, and assignee changes contribute to heat. Tickets are “hot” as long as ticket activity continues.
High heat indicates that there has recently been activity on that particular ticket. If the ticket is currently in a Not started state and requirements are being gathered , high heat is expected given the workflow.
Heat will build when activity occurs on a ticket regardless of the status the ticket is currently in, because heat is not state dependent .
Jitter is a configurable measure of ticket activity while a ticket is in a not started, active, or done state. Jitter does not decay over time. Ticket activity like comments, body modification, and assignee changes, contribute to jitter, but only when that activity occurs in a status mapped to an not started, active, or done state.
Ticket jitter indicates the amount of activity that occurred on a ticket while an engineer was actively working on it. For example, this could mean that requirements were unclear and had to be refined between engineering and product, or there were multiple development and review cycles that occurred on the ticket.
If you need help, please email firstname.lastname@example.org for 24/7 assistance.