Flow Performance & Variant Explorer

Flow Performance takes the workflow your team actually runs and lays timing over it, so you can answer three questions at a glance: where does work wait the longest, how long does delivery really take, and which routes does work follow from start to finish?

It shares its map with Workflow Discovery, but the two answer different questions:

• Workflow Discovery is the structure view: what your workflow looks like and where you set up how statuses and people are grouped.
• Flow Performance is the performance view: where that workflow is slow and which routes work takes.

If the map looks sparse or mislabeled, set things up in Workflow Discovery first. Flow Performance reads the same workflow.

Drawing the map

Pick a project, optionally narrow to an issue type and a time range (the last 30 days by default), then press Mine. The site is named beside them, as on Workflow Discovery, and is a list to pick from only when your organization has more than one Jira site sending events. The map is built from your real ticket history for that window, the same way as on Workflow Discovery: one press is one analysis, kept as a snapshot rather than a live view. Pressing Mine again with the same filters can reuse an analysis from up to an hour earlier; press Re-mine for a fresh one. Workflow Discovery explains what one analysis reads and what the counts under the map mean.

How to read it

The map. Each step is a state your work passes through; each box between two steps is a hand-off between them. A hand-off, its box and its arrows, is shaded green → red by the average time work waited before it, and its arrows grow thicker as that wait grows, so the slowest parts of your process stand out. The colors compare hand-offs within one map, not across maps or dates. Steps are drawn larger the more often issues visit them; no arrow's width shows volume. Hover a hand-off to see its average wait and how many times issues made it.

The header. Two delivery-time figures for the issues delivered in the window you mined, counted over delivered issues only (work closed as abandoned or a duplicate is left out), beside the number of those completed issues:

• Median (typical) cycle time: half your completed work finishes faster than this.
• Slow-tail cycle time (85th percentile): most work finishes within this; it captures the slow cases the median hides.

Watching both together tells you whether your process is consistently quick or usually quick with a painful tail.

Where work waits. A side panel lists up to 12 of your Jira statuses, ordered by how long work sits in each, with a typical (median) and a slow-case (90th percentile) figure per status; hover a row to see how many times work left that status. A status that work left fewer than five times is marked few departures and listed after the well-sampled statuses of its group, since one slow case can set its figure. A status Jira counts as done is grayed and listed after the waiting ones, because finished work is not queued. The panel follows the window you mined: a wait counts in the window in which work left the status, at its full length, so a wait that began earlier counts in full and work still sitting in a status is not counted until it moves on. If no work left any status in the window, the panel says there is nothing to show rather than listing zeros. It covers every issue type, so it can list a status that the map draws inside one of your lanes, or one the map leaves out.

The Variant Explorer

Real work rarely follows one tidy path. The Flow variants panel lists up to 15 of the distinct end-to-end routes work actually takes, ranked by how many issues followed each, with each route's share of the issues on the map. Each route is labeled by the steps it passes through, such as To do → In progress → Done. Two routes through the same steps are listed separately when they differ in something else the map tracks: the issue type, whether the issue had an assignee or a resolution at a step, or its fix versions or linked commits. The label then names that difference, for example Story · Inbox → To do beside Bug · Inbox → To do. Routes that loop back (rework) or skip steps show up as their own variants. A long route shows its first and last steps; hover over it to read the whole route.

Click a variant to light up that exact route on the map and dim everything else, so you can trace it step by step. Timing is measured per step, not per route: each hand-off's shading is the average wait across every issue that made it, whichever route it was on, so the list tells you which routes are most common, and the map where work waits longest along them.

Replaying an earlier point in time

The As of date slider replays the map as it looked on an earlier date, up to a year back. Drag it back and release to mine the workflow again for the window ending then, useful for "did this bottleneck exist last quarter?" The cycle times and Where work waits follow the same window, so all three describe the period the map shows.

Ask the AI

Analyze runs three analyses of the map at once, each under its own heading: Where work waits, Most common routes and a plain-language Flow summary. If one of them fails, its heading says so and the other two still answer. The Ask Flow box answers free-form questions like "which route do most issues take?" or "where do issues pile up?" in plain business language. Both go through your organization's AI provider. Each request names the window the map was mined for and gives every time as the page shows it; Where work waits and the cycle times cover that same window, for every issue type.

Tips

• Start wide, then narrow. Mine all issue types first for the overall picture, then scope to one type (e.g. just Bug) for a leaner map.
• Use the filter threshold to hide one-off paths and keep the map readable; lower it to surface edge cases.
• Pair it with Workflow Discovery. If statuses sit outside the lanes as gray circles or the lanes look wrong, fix the groupings there. Flow Performance will read cleaner immediately.