Flow Metrics
Flow Metrics describe how quickly and how smoothly tickets move through the work process, from creation to completion. Unlike most other metrics in Q247, they are calculated at the ticket level, not the commit level, and require an integration with a ticketing system (Jira).
This entire group appears only when a project has a configured integration with Jira. The metrics are calculated at the project level, because a ticket usually passes through several people's hands (the author, reviewer, tester) and describes the efficiency of the process, not the contribution of one person. Lead Time and Cycle Time also appear as columns in the project table on the Overview, and Work in progress also appears on the Participant card. The Team view has no cards from this group.
Default measurement boundaries
The points in time from which and to which the duration is measured are set in Configuration. An organization that has not changed them measures using the default values, based on Jira's native status categories:
| Point | Default |
|---|---|
| Start of Lead Time | ticket creation |
| Start of Cycle Time | first entry into any status in the "In Progress" category |
| End of both metrics | first entry into any status in the "Done" category |
| Ticket types included in the calculations | all |
In Jira, a status category covers many statuses at once, so the default start of Cycle Time also falls on entry into statuses named "In Review" or "In Development", and the end falls on "Closed" or "Deployed" the same as "Done". For most processes this gives a sensible result without any configuration, and it is worth changing the boundaries only once the process in Jira assigns statuses to categories differently than the real moment work is picked up and finished would suggest.
Lead Time
The median number of business days from ticket creation to its completion (moving into a status marked in Jira as final, e.g. "Done"), calculated only from tickets that have actually reached such a status.
This is the ticket's full lifetime from the reporter's perspective: it also includes the time before anyone started working on it (queuing, prioritization). A rising Lead Time alongside a stable Cycle Time (below) points to a problem with queuing or prioritizing work, not with the pace of doing it. It is a median, not a mean, so a single ticket that has been hanging around for a very long time does not distort the result the way it would distort a mean.
Cycle Time
The median number of business days from the start of work on a ticket (entering the "In Progress" status) to its completion. Calculated only from tickets already completed.
The exact statuses that count as the start and end are configurable for the whole organization, with the option to override them per project.
Unlike Lead Time, it measures only the real execution time: from the moment someone actually started working. A rising Cycle Time with unchanged ticket complexity usually points to team overload, blockers during work (e.g. waiting for a review or a test environment), or tickets that are too large. It is worth comparing it with Work in progress (below): a high Work in progress together with a rising Cycle Time is the typical picture of a team starting more than it can currently finish.
Throughput
The pace of completing tickets, expressed as the number of tasks per week.
It shows pace, not volume of work: ten small tickets and two large epics can produce very different Throughput with a similar real workload, if the team splits work into uneven pieces. It is useful mainly for tracking the trend over time for the same project (whether the pace is rising, falling, or stabilizing), and less for comparing different projects with each other, because they may have completely different cultures of splitting work into tickets.
Flow velocity
The number of tickets completed in the selected period.
This is the raw number of tickets completed over the selected period, without the weekly normalization that Throughput applies. When comparing periods of different lengths, this difference has to be taken into account. Set alongside Flow distribution (below), it speaks to the amount of work, while Flow distribution shows its kind.
Work in progress
The number of tickets in the "in progress" status at the end of the selected period. On the Project view it is additionally shown as a value per developer: Work in progress divided by Effective Team Capacity.
A high Work in progress per person is a sign of multitasking: the more tickets a single person holds at once, the more context switching there is, and usually the longer the Cycle Time of each individual ticket, even if the overall Throughput looks fine. A low value usually means work focused on one task at a time, which shortens the Cycle Time of individual tickets.
Flow distribution
The split of completed tickets into two categories: features and bugs. The type names belong to the ticketing system, so it is the administrator who assigns specific names to one of these groups, in Configuration, with the option to override this per project. Types with no assignment, for example Epic or Sub-task, are reported as "Other", so the sum of the three groups always matches Flow velocity, while the sum of features and bugs alone can be lower than it.
Business days
All the metrics above are calculated in business days, excluding the holidays defined in the organization's work calendar (shared across the whole organization, not per project).