Flow Efficiency — the active vs waiting time of your tickets
A ticket takes 8 days to ship. Two of those days are someone working on it. Six are waiting. Avium tells you which is which.
Where time actually goes
Cycle time is the easy metric — how long from start to done. It hides the most actionable detail: of the 8 days a ticket sat in flight, only 2 were active development. The other 6 were code review queues, QA queues, waiting for a stakeholder decision, waiting for a deploy window.
Flow efficiency is the Lean ratio that exposes this gap. Teams stuck below 25% are often debugging the wrong problem — they're hiring engineers when the bottleneck is the approval queue.
How teams try to read process bottlenecks today
Hard to do by hand:
- Eyeballing the in-progress column for tickets that 'feel slow' — no comparison, no trend.
- Counting time-in-status from Jira's history view — works for one ticket; doesn't scale.
- Process-mining tools (Celonis et al.) — overkill, enterprise pricing, never adopted by scrum teams.
- Cycle time charts — tell you HOW LONG but not WHERE THE TIME WENT.
How Avium Signals computes flow efficiency
Avium reads every ticket's phase transition history and time-log entries.
- Active time: sum of time logged on the ticket (or, when no time logs exist, the time spent in phases tagged as in-progress or development).
- Total time: time elapsed from first non-backlog transition to first done transition.
- Flow efficiency = active / total. Reported as a percentage.
- Per-phase dwell: breakdown of where total time was spent. Reveals the specific bottleneck (e.g., 'code review averages 3.2 days; engineering averages 1.1 days; the slowness isn't in writing code').
Who reads this Signal
See your flow efficiency
Avium computes flow efficiency the first time you connect your work management tool (Jira today, more integrations on the way). Per-phase breakdown is on Team; the AI Briefing layer on Business explains the bottleneck in plain English.
Start free — no credit card →