Flow Performance & Variant Explorer(5.11.1)

This visual lays delivery timing over your real, discovered workflow, so you can see not just how work flows but where it waits longest along the way.

What you can conclude

• Which moves between steps follow the longest waits.
• Which steps work passes through most often: the most visited steps are drawn larger.
• Which end-to-end routes work actually takes, and how many issues follow each. Timing is measured per step, not per route: a move's shading averages every issue that made it, whichever route it was on.
• How your workflow and its timing looked at any past point, by replaying it with the date slider—useful for checking whether a process change actually helped.
• Both the typical experience and the slow tail, by reading the median alongside the 85th-percentile figure.

How this chart works

Each move between two steps, its box and its arrows, is shaded from green to red by the average time work waited before making that move, and its arrows are drawn thicker as that wait grows. The scale runs from zero to the longest average wait on the map in front of you, so a color compares moves within one map, not across maps or dates. Steps are sized by how often issues visited them, and no arrow width encodes volume. A list below the map ranks up to 15 of the distinct routes work takes from start to finish, most issues first, each labeled by the steps it passes through and showing its number of issues and its share of the issues on the map; selecting a route traces it directly on the map. Two routes through the same steps are listed separately when they differ in something else the map tracks, such as the issue type or whether the issue had an assignee or a resolution at a step, and the label names that difference. A date slider replays the workflow as it appeared on any day in the past year: releasing it mines the map again for the window ending that day, and the cycle times and the side panel follow that window. The cycle times above the map are shown as both a median and an 85th-percentile figure, so a fast typical case never hides a slow tail, and hovering a move shows its average wait and how many times issues made it. The cycle percentiles and the completed-issue count cover the issues delivered within the window the map was mined for, so they move with the time range and the date slider; they count delivered issues only, and closures into abandoned or duplicate statuses are not counted as completions. An on-page assistant can answer questions about specific steps or routes.

This view builds on the workflow shown in Workflow Discovery—configure your status and actor groupings there and they carry over here.

What one analysis is

The map is mined the same way as on Workflow Discovery, from the same kind of selection: a site, a project, optionally an issue type, and a window (the last 30 days unless you pick another). Pressing Mine runs one analysis and keeps it as a snapshot rather than a live view; pressing it again with the same filters can reuse an analysis from up to an hour earlier, and Re-mine runs a fresh one. One analysis reads at most 50,000 of the project's events in the window; when the window holds more, it keeps the most recent, a line under the map names the date and time from which the map is complete, and the routes, shading and counts describe those recent events rather than the whole window. The Workflow Discovery description explains what one analysis reads and when a kept one is reused.

What the step timings measure, and what they leave out

• A step's timing is the gap between one status change and the next, so it only counts work that later left that step. Work parked at a step right now contributes nothing to it until it moves, and a step holding blocked work can therefore appear faster than it is.
• No upper limit is applied to a wait. A genuinely long wait is reported at its full length, which is the point on this map: the moves that follow weeks of waiting are exactly what the shading is there to reveal.
• Check how many times issues made a move, shown when you hover it, before treating its shading as a property of the move rather than of one slow item: the shading is an average, and one long wait can set it.
• The end-to-end cycle figures above the map are a separate measurement over delivered issues and are not affected by any of the above.

A step is identified by its Jira status id, so a renamed status is one step under its current name, and a wait that spans an issue's move between projects is measured rather than dropped, credited to the project where the issue left the status.

Where work waits

• The side panel lists up to 12 of the project's Jira statuses by the median time work spent in each before moving on, with the 90th percentile beside it. Hovering a row shows how many times work left that status, so a figure resting on one or two departures can be told apart from a well-sampled one. A status that work left fewer than five times is marked few departures and listed after the well-sampled statuses of its group, waiting or completed.
• It follows the time range and the date slider. A wait is counted in the window in which work left the status, at its full length: a wait that began before the window and ended inside it counts in full, and work still sitting in a status when the window ends is not counted until it moves on. When no work left any status in the window, the panel says so rather than listing zeros.
• It covers every issue type, because the issue type filter applies to the map and its routes only. It names Jira statuses, while the map draws the lanes you grouped them into in Workflow Discovery, so a status can be listed here that the map draws inside a lane, or that the map leaves out.
• A status in Jira's Done category is grayed and listed after the waiting statuses, because work there has finished rather than queued. Whether a status is completed is decided per project, because the same status name can be completed in one project and still open in another.
• Where one name covers Jira statuses that disagree within the project (or, where the project never showed the status itself, across the Jira site), or the status was never seen with a Jira status category, the status is left in the ranking rather than guessed.
• A completed status only shows a time for work that later left it, such as a reopened issue, so its figure is a sample of departures, not the time since completion.

Reading the counts under the map

The line under the map is the same accounting as on Workflow Discovery: issues on the map, issues that never changed state, and issues dropped by the rare-path filter add up to the issues with activity in the selected window, and the Workflow Discovery description explains each count.