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: A user is given credit for the metrics associated with a ticket if they were ever an assignee of the ticket once it moved into its first Active state. When filtering by teams, all tickets where any member of the team were an assignee of the ticket after it moved into its first Active state count for the team.
Who can use this?
| Core | Plus | ||
| ✓ | ✓ |
Tickets completed
Tickets completed is the total number of tickets that moved to their final status in a Done state during the selected time period. Tickets in a canceled state do not count toward Tickets completed.
Cycle time
Cycle time is the time between when a ticket enters an Active status and the final Done status in its lifecycle. 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.
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 lifecycle.
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.
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%
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.
Velocity
Velocity is the total number of story points completed in a period. Use Velocity as a measurement of how much work you complete.
To calculate Velocity, sum the total story points for each ticket moved to a Done state in the period. Story points associated with tickets in a canceled substate do not count toward Velocity.
Note: To calculate Velocity correctly, Flow needs to access the field that stores your story point information. Flow uses these fields by default. If you use a custom field for your story point information, set up custom mapping for story points in your ticket project configuration. Typically, velocity will show as zero if you need to update your story point mapping.
If you need help, please contact Pluralsight Support.