Backflow rate is a measure of how often your tickets move backward through their status workflow.
In this article
Which reports use Backflow rate?
See Backflow rate in Metrics overview and Retrospective.
See Backflow rate for individual tickets in Sprint movement and Ticket log.
What does Backflow rate measure?
Backflow rate tells you how often you're losing progress on your tickets by moving them to a status earlier in your workflow. A high Backflow rate indicates a ticket went through multiple reviews and modifications before being completed.
Usually, you'll see Backflow rate being caused primarily by transitions from testing back to active development or active development back to planning.
Tip: Use the View details dropdown in Retrospective to identify which status transitions are causing your Backflow rate to increase.
How is Backflow rate calculated?
Backflow is based on your ticket project configurations, particular the arrangement of the lanes in your status mapping.
Backflow rate is calculated as Backflow transitions / Total transitions
A transition occurs when a ticket moves from one lane to another. A status change within a lane is not a transition.
A transition across multiple lanes 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 lane.
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 status under Backlog, to the Selected for Development status under Ready, to the In Progress status under In progress, then to the Pending QA status under Testing. Each of these moves is a transition.
After this, the ticket moves to the Out for review status 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 status under In progress. This move is a backflow transition because the ticket moved to an earlier lane.
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 = 1/4 = 25%
When calculating the Backflow rate for multiple tickets, the total is calculated as: Total number of Backflow transitions across all tickets / Total number of transitions across all tickets
The total Backflow rate cannot be calculated by taking the average of the Backflow rates of all tickets.
What data is included in Backflow rate?
All lane transitions are included in the Backflow rate calculation, including those from any status back to an unassigned status. Because the calculation depends heavily on your ticket project configurations, ensure all statuses have been mapped correctly.
Tickets are included in Backflow rate if:
- They are moved to their final Done status during the selected time period
- The selected user or member of the selected team was an assignee on the ticket at any point once it moved into an Active status
Tickets aren't included in Backflow rate if:
- They haven't been moved to a Done status
- They are in a Canceled status
- The selected user or member of the selected team has never been an assignee on the ticket or was only an assignee before the ticket moved into an Active status
- The ticket has never had an assignee
- Their issue type has been excluded as part of ticket type assignment in ticket project configuration