Cycle Time by Priority(2.7.6)

If your team uses priority correctly, Highest issues should resolve significantly faster than Low ones. If they don’t — if the distributions overlap heavily — it means priority is being assigned inconsistently, or that the team doesn’t have a mechanism for actually accelerating high-priority work once it’s in flight.

This visual shows the average cycle time for each priority level alongside the worst single (project, day) P90, so you can see not just typical speed but the worst pocket of delay inside each priority.

What you can conclude

• A large gap between Highest and Low average cycle times is what working priority triage looks like.
• Similar average cycle times between High and Medium suggest that these two levels are not being treated differently — one is redundant.
• A worst-day P90 far above the average for any priority level means delivery is inconsistent — some issues in that category take much longer than others for unclear reasons.

How this chart works

Grouped bar chart per issue priority: the average cycle time (creation to first delivered transition), weighted by delivered issues so it is exact for the priority, next to the highest single (project, day) 90th percentile recorded in it. Per-project averages compose exactly; per-project medians do not, which is why no cross-project median is shown. Issues closed as discarded or canceled are excluded from the timing and carried in the abandoned count of the same row. Priority is read at delivery: the value recorded when the issue was created, updated by the last recorded priority change before delivery; issues whose priority was never recorded appear as None. Use the project filter to compare priority-speed alignment across teams.