Ticket metrics

Tags: Flow

Ticket metrics are found in the Ticket log, Retrospective, and Sprint movement reports. Ticket metrics help you manage workflow and efficiency.

This article goes over the details of these metrics and how these metrics correspond to ticket configurations. Learn more about ticket configurations.

Note: Ticket log is available on Flow Core and Plus plans. Retrospective and Sprint movement are only available on the Flow Plus plan.

Who can use this?

 Core
Plus
 
  


Cycle time

Cycle time is the time between when a ticket enters an Active status and the final Done status in its life cycle. Use Cycle time to determine how long a ticket took to complete.

Cycle time is only calculated when a ticket is marked with a Done status. Any tickets marked with Not started or Active statuses don’t have a calculated cycle time.

Cycle time updates when tickets move backward from a Done state.

Cycle time only captures the time a user actively worked on a ticket. It doesn’t include lead time when product managers, designers, or stakeholders provide requirements before the ticket enters an Active state

For example, the screenshot below shows a Ticket project configuration page with three ticket lanes: In progress, Testing, and Done. The In progress and Testing lanes have an Active status, while the Done lane has a Done status.

Cycle time for a ticket in this process begins when the ticket enters the In progress lane, giving it an Active status. Cycle time for this ticket ends when the ticket enters the Done lane, giving it a Done status.

back to top


Queue time

Queue time is the total time a ticket is in a waiting state.

An engineer working on a ticket may need to wait for feedback, QA, or review from team members. Queue time captures these moments in a ticket’s life cycle.

A queue time of zero hours means the ticket has never been in a waiting state. Once a ticket enters a waiting status, its queue time starts to accrue.

Assign a status to a Waiting state when setting ticket configurations. Learn more about setting ticket configurations.

back to top


Backflow rate

Backflow rate is the percentage of status transitions that move a ticket backwards through the ticket process.

A high backflow rate indicates a ticket went through multiple reviews and modifications before being completed.

How Backflow rate is calculated:

Backflow rate = Backflow transitions / Total transitions

A transition occurs when a ticket moves from one lane to another. A status change within a column is not a transition.

A transition across multiple columns at a single time only counts as a single transition for that ticket. For example, in the image below, moving a ticket from Backlog to In Progress would only represent one transition for that ticket.

A backflow transition occurs when a ticket moves back to a previous column.

For example, the image below shows five lanes representing the ticket process: Backlog, Ready, In progress, Testing, and Done.

A ticket moves from the New section under Backlog, to the Selected for Development section under Ready, to the In progress section under In progress and then to the Pending QA tab under Testing. Each of these moves is a transition.

After this, the ticket moves to the Out for review section under Testing. This move isn’t a transition because both Pending QA and Out for review are in the same lane. Therefore, they are mapped to the same status.

Finally, the ticket moves to the Reopened section under In progress. This move is a backflow transition because the ticket moved to an earlier state.

This example ticket underwent four total transitions. One of the transitions was a backflow transition.

The Backflow rate for this ticket is:

1 Backflow transition / 4 Total transitions = ¼ = 25%

back to top


Jitter

Jitter is a configurable measure of ticket activity while the ticket is in an Active state. Jitter indicates the amount of activity that occurred on a ticket while an engineer was actively working on it.

A high Jitter could mean a ticket’s requirements were unclear and required additional communication between engineering and product. It could also mean a ticket had multiple development and review cycles.

Jitter is calculated on a per ticket basis. Total jitter represents the sum of all ticket jitter.

How Jitter is calculated:

First, Flow calculates the Jitter for an individual Jitter event on a ticket:

Jitter for a specific event type in a ticket = Number of times that Jitter event occurred * (Weight of that Jitter event / Sum of all Jitter event weights in the ticket project) * 100

Then, Flow adds together the Jitter from each event type on the ticket to find that ticket’s Jitter:

Jitter for a ticket = Sum of Jitter for a Jitter event in a ticket

Finally, Flow calculates Total Jitter of tickets in a filter by adding together the Jitter on all tickets with Jitter in that filter:

Total Jitter of tickets in a filter = Sum of Jitter for all tickets in that filter

Edit event weights for projects in ticket configurations.

Jitter doesn’t degrade over time.

A ticket accrues Jitter when:

  • It’s mapped to an Active status and gets activity.
  • It’s mapped to an Active status column with a sub-status that’s marked Waiting and gets activity.

Examples of ticket activity include comments, body modifications, and assignee changes.

A ticket doesn’t accrue Jitter when:

  • It’s not mapped to an Active status.
  • It’s mapped to a Not started or Done status.

back to top


If you need help, please email Support (opens email form) for 24/7 assistance.