Where the time actually goes — candidate visualizations on REAL data (same cohort and rules as everywhere). Pick the ones worth showing.
Interactive: click any status (segment, row, legend chip) to highlight it across ALL views — timelines re-rank by time spent in it; click again to clear. Ticket keys open Jira. CFD legend toggles bands.
A · Pipeline — where a ticket's time lives
iHow to read it
Take every completed ticket, cut its Cycle (work start → done) into the statuses it sat in, and add the pieces up. The top bar shows the shares of ALL cohort time; the rows below rank the same statuses. 'med' = median days per visit, 'Σ' = total days the whole team left in that status. AGGREGATIONS USED HERE: the bar widths, Σ and % are SUMS of ticket-days (sums are what define the bottleneck — who ate the most time in total); 'med' is the MEDIAN (the document default, robust to outliers). The Overview aggregation toggle (avg/P75/…) deliberately does NOT apply on this page: switching the median would not change the ranking (it is sum-driven), and the worst-ticket tail is already shown literally — click a status for its top-15 longest tickets.What a problem looks like
A WAITING status (review/merge/test queues, On Hold) holding one of the biggest shares. In Progress on top is normal — that's the work itself; the red badge marks the biggest WAITING eater.median + ΣOne bar = the whole Cycle (work start → done), split by status. Width = share of all cohort time. The widest segment IS the bottleneck. Below — the same statuses ranked: median per visit · total days · share.
Bottleneck: Ready For Review — 48.6% of all time (Σ 25.8d, waiting). All waiting combined: 80.5%; the work itself (In Progress) — 15.2%.
B · Flow efficiency — work vs waiting
iHow to read it
EXACT rules. Cycle: first entry into work → done, CALENDAR days — weekends and holidays INCLUDED (the document standard), time after a bounce back to the New category SUBTRACTED. Active: for every calendar day, the ticket's hours in NON-passive statuses count; the day contributes 0 if it is Sat/Sun, an approved vacation of the assignee (BambooHR, linked by work e-mail — 90 of 91 employees linked) or a public holiday of the assignee's country (country from BambooHR); at most 8 working hours count per day (the cap); the hour total ÷ 24 gives 'days' on the same scale as Cycle. People without a BambooHR link (e.g. AI agents) are computed WITHOUT the vacation subtraction — disclosed by a 'no HR' badge. ONE WORKED EXAMPLE: work starts Thu 10:00, done Mon 10:00 → Cycle = 4.0d (Sat+Sun included). Inside it: Thu 8h of work (capped), Fri = the assignee's vacation → 0h, Sat/Sun weekend → 0h, Mon 1h. Active = 9h ÷ 24 ≈ 0.4d. CALENDAR efficiency 0.4/4.0 = 10% — looks scary. PROCESS efficiency: the working time available in the flow was the same 9h (Fri/Sat/Sun are not working time) → 9/9 = 100%: there were NO queues, all the 'waiting' was the calendar itself. UNITS: both BARS are percentages — the unit cancels and never moves them; the absolute hands-on figures in the captions follow the Active unit picked in the filter bar (calendar d / working days / hours). TICKET-DAYS: the breakdown sums over EVERY cohort ticket — tickets run in parallel, so 100 tickets in a 30-day window can accumulate thousands of ticket-days; hundreds of days in the breakdown is arithmetic, not an anomaly. AGGREGATIONS USED HERE: the calendar bar is a ratio of MEDIANS (typical Active ÷ typical Cycle — the document default); the process bar and the waiting breakdown are SUMS. The Overview aggregation toggle does NOT apply by design: a ratio like P75(Active)÷P75(Cycle) would divide numbers taken from DIFFERENT tickets and has no honest reading.What a problem looks like
Look at the PROCESS bar and the 'where the waiting goes' breakdown: NAMED queues (Ready To Merge, On Hold, Ready To Test) are a manageable bottleneck; the nights/weekends/vacations row is not. The 5–15% reference for calendar flow efficiency is a range commonly cited in Lean/Kanban literature (Modig & Åhlström 'This is Lean', Vacanti) — it is NOT our measurement, so compare the team against its own previous window rather than a book. Alarm signs: the process efficiency FALLS window over window, or one named queue keeps growing.median + ΣTWO views. The big CALENDAR bar: median Active vs median Cycle — Cycle runs on the calendar (weekends and holidays INCLUDED, as the document demands; time after a bounce back to New is subtracted), Active counts working hours only. The PROCESS bar below removes calendar physics: BOTH sides count only the assignee's working hours (weekdays, minus their BambooHR vacations and country holidays, capped per day) — its remainder is pure process queues.
Of the median 1d cycle, hands-on work is 0.4d (= 1.2wd): the ticket waits 60% of the time.
40% hands-on work
60% waiting
process efficiency (assignee working hours only) · hands-on 44.7wd of 52.5wd working time in flow
85.4%
14.6% process queues
where the waiting goes · 38.1d cohort total — TICKET-days of 25 parallel tickets, hence far above the window length
C · Ticket timelines — the last tickets as segments
iHow to read it
Each row is one real ticket, left edge = work start, right edge = done; colored pieces = statuses (hover a piece for status + days). Rows are sorted longest-first. The legend below names only the statuses that actually appear.What a problem looks like
The same color dominating many rows = everyone stuck in the same stage. One giant single-color row = an outlier worth opening (the key is right there).Each row = one real completed ticket from work start to done; colored segments = statuses. Long same-color stretches across many rows point at the same stage — that's the bottleneck pattern, outliers included.
Longest single stay here: In Progress — 5.4d in ADS-670. Click a status in the legend to rank tickets by it.
D · Aging WIP — what is stuck right now
iHow to read it
Only tickets IN WORK right now (In-Progress-category status), ranked by days since their last status change. Green ≤ 7d, amber > 7d, red > 30d. Backlog rot is excluded on purpose — it is not work in progress.What a problem looks like
Red rows are today's bottleneck, ticket by ticket — each one is a concrete 'why is this stuck?' question for standup.Open tickets that have not moved the longest (days since the last status change). This is the operational view: today's bottleneck, ticket by ticket.
E · Cumulative flow — queues over time
iHow to read it
Week by week: how many tickets sat in each In-Progress-category status (stacked). Backlog statuses (To Do, Open…) and done are excluded so the work queues stay readable. The height of a band = the size of that queue that week.What a problem looks like
A band that keeps getting taller = a queue that keeps growing — work arrives faster than that stage digests it. A stable thin band is healthy.Tickets in each WORK stage, week by week (backlog and done excluded — they drown the queues that matter). A band that keeps widening is a queue that keeps growing — the classic bottleneck signal and its history.
The fastest-growing queue is In Deployment: 0 → 3 tickets across the window.