Flow metrics — cycle time, work mix and planning accuracy

Three reports read the shape of delivery rather than its cost: how long work takes, what kind of work it is, and how well it was planned. Each is built from data you already sync — status transitions, classifications, estimates and worklogs — and each is honest about the tickets it can't include.

Flow Health — cycle time

The Flow Health report (its page is at reports/cycle-time) measures how long tickets take from start to done.

• Start is the earlier of the first commit linked to the ticket, or the first time it moved out of a not-started status (To Do, Backlog, Open).
• Done is the first time it moved into a done status (Done, Closed, Resolved, Released).

A ticket only counts if it has that history: with no status transitions and no linked commits there is no start or end to measure, so it's left out rather than counted as zero.

The report leads with the median cycle time and the p90 — the ceiling nine in ten tickets come in under. Median tells you the typical case; p90 tells you the tail, which is usually where the pain is. A ticket taking more than three times the median is flagged as an outlier so a couple of stuck tickets don't quietly distort your read — but outliers are flagged, not removed: they stay in the median, p90 and counts. When p90 runs beyond three times the median, the report warns that the tail is stretched.

Work Mix

The Work Mix report (page reports/work-type) breaks effort hours down by work type — Feature, Maintenance, Support, Technical Debt — as hours and as a share of the total. The types come from each entry's classification; work nothing classifies falls back to Support.

Read it as a balance, not a target: a high Support-plus-Technical-Debt share means operating load is crowding out feature work, which is a staffing and prioritisation conversation, not a number to optimise for its own sake.

Planning Accuracy

The Planning Accuracy report (page reports/estimation) compares logged time against the original estimate:

accuracy = actual time logged ÷ original estimate

It uses the Jira original estimate and the worklogs for the period, and only includes tickets that have both — an estimate and logged time. A ticket missing either can't be scored and is left out. Over 100% means the work took longer than estimated (shown as "over plan", the same tickets the panel calls "under-estimated" — the estimate was too low); under 100% means it came in below estimate. Tickets within ten percent either way count as on-target.

Aggregate accuracy is weighted by time, not a plain average of ratios, so a big ticket moves the number more than a small one. Because it needs logged time and estimates, this report is only available when your organisation's effort method is worklogs; on commit-session effort there's nothing to compare.

What the numbers mean

• Cycle time is observed, measured from your own status and commit history; its quality rides on tickets actually moving through statuses.
• The work mix is only as good as your classification — the same rules the capitalisation split depends on.
• Planning accuracy compares estimate against logged time; it says nothing about tickets that were never estimated or never logged, and it's a calibration signal, not a scorecard for a person.