Avium SignalsTeam tier and above

Time in Status — where work actually sits in your workflow

Your team isn't slow. Your tickets are sitting somewhere. Avium tells you which somewhere.

Avium SignalsWorkflow / Ping-Pong
Work isn’t a straight line — Avium counts the backward hops that quietly burn the sprint.
↺ 9× reworkTo DoIn ProgressIn ReviewDone

Where the time actually goes

A ticket takes 9 days from start to ship. The team is asked to be faster. They work harder; the time doesn't change. Because the 9 days included 4 days in code review queue, 2 days in QA queue, and 3 days of actual work. Engineers working harder makes the 3-day portion shorter and changes nothing else.

Time-in-status is the diagnostic. The bottleneck is named. Then the right intervention happens — change the review SLA, add a second reviewer, automate the QA step — instead of a team motivational speech.

How teams try to read time-in-status today

Jira hints at this but doesn't put it together:

  • Jira's Control Chart shows cycle time but doesn't break it down by phase.
  • Cycle Time + Lead Time reports exist but require enterprise plugins to slice usefully.
  • Spreadsheet exports of ticket history — possible, painful, never repeated.
  • Looking at the in-progress column 'feels heavy' — descriptive, not diagnostic.

How Avium Signals computes time in status

Avium reads every status transition and computes dwell time per phase across the org's tickets.

  • Average dwell per phase: across the last N closed sprints, mean time tickets spent in each phase. Read top-to-bottom of your workflow.
  • Median dwell per phase: less sensitive to outliers; often the better summary.
  • Currently stuck list: every open ticket sorted by current-phase dwell. The longest-stuck tickets are usually the right standup discussion.
  • Trend: is dwell in a given phase climbing over time? Often the first signal of a process problem (e.g., one reviewer leaving makes review-queue dwell climb).

Who reads this Signal

Scrum masters
The right standup conversation is rarely 'are we on track' — it's 'why is this ticket stuck.' Time-in-status surfaces the stuck list.
Agile coaches
Lean coaching with data. Targeted process changes — 'we need to cut review-queue time by half' — beats general 'we need to be faster' nudges.
Engineering managers
Diagnose your bottleneck before you intervene. Adding people to a team whose bottleneck is review doesn't help. Knowing this beforehand saves a quarter.
VPs of engineering
Compare time-in-status across teams. The team whose review queue is 5 days isn't the same team as the one whose review queue is 1 day, even if cycle time matches.

See where your tickets sit

Avium computes time-in-status as soon as your work management tool is connected (Jira today, more integrations on the way). Per-phase breakdown + stuck-ticket list on Team; the AI Briefing's interpretation ('your code review queue has grown 40% over two months') on Business.

Start free — no credit card →

Related Avium Signals