Delivery & Velocity
iONE shared time axis (weeks) and one scale (days) for every time metric — exactly as asked in the meeting. Default lines: Cycle, Lead, Active; Time-to-1st-PR, Lead-Time-for-Changes and every per-status line start OFF — click a chip above the chart to toggle it. Each point = the median over tickets that finished that ISO week. What to look for: lines drifting up over weeks = delivery slowing down; a status line rising = that stage clogging.ADSEVO|30d90d180d365d|allagentshumansiThe three filters apply to EVERY number on the page. Project = the Jira project (team). Window = completion window: a ticket belongs to it when its LAST transition into a done status falls inside [start, end) — created-long-ago tickets still count if finished now. all/agents/humans = ticket assignee against the AI-agent roster. Deploy/PR/Bug metrics follow the project and window; they ignore the who-filter (a deploy has no assignee, a bug counts by its reporter's ticket, not an assignee).
Time metrics — click to focus the chartActive:cal. dayswork days°hours
Lead Time (median)iWhat it means
The Lead Time should measure the time between when the ticket was created until it is done. The purpose is to measure the full end-to-end customer experience. (Lead Time (MUST HAVE), p.3)How it's computed
Headline = MEDIAN days over every ticket completed in the window; “View tickets” lists each ticket with its own lead time.Example
Created Mon 09:00 → entered Done Thu 09:00 = 3.0 d. Calendar days: a weekend in between would count too.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →—d
The Lead Time should measure the time between when the ticket was created until it is done. The purpose is to measure the full end-to-end customer experience. (Lead Time (MUST HAVE), p.3)How it's computed
lead = done_at − created_at // calendar days — weekends & holidays counted
done_at = moment of ENTERING a done status [Done, Resolved, Closed] (last such entry in window)
// time spent INSIDE the done status is NOT counted
cohort − issue types [Epic]The numbers shownHeadline = MEDIAN days over every ticket completed in the window; “View tickets” lists each ticket with its own lead time.Example
Created Mon 09:00 → entered Done Thu 09:00 = 3.0 d. Calendar days: a weekend in between would count too.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →—d
created → done, waiting included
Cycle Time (median)iWhat it means
The Cycle Time should measure the time from when the ticket is put in progress until it is done. The purpose is to measure the actual work that was done. (Cycle Time (MUST HAVE), p.3)How it's computed
Median days from the FIRST entry into an In-Progress-category status to done. Tickets that were never started have no cycle (they still count in Lead).Example
In Progress Tue 09:00 → Done Fri 09:00 = 3.0 d. If it bounced back to To Do for 1.0 d in between → 2.0 d.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →—d
The Cycle Time should measure the time from when the ticket is put in progress until it is done. The purpose is to measure the actual work that was done. (Cycle Time (MUST HAVE), p.3)How it's computed
cycle = done_at − first(status of Jira category “In Progress”) // done_at = ENTRY into a done status; time inside it not counted − Σ(time in “new”-category statuses after start)
// calendar days — weekends & holidays countedThe numbers shownMedian days from the FIRST entry into an In-Progress-category status to done. Tickets that were never started have no cycle (they still count in Lead).Example
In Progress Tue 09:00 → Done Fri 09:00 = 3.0 d. If it bounced back to To Do for 1.0 d in between → 2.0 d.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →—d
In Progress → done
Active Work Time (median)iWhat it means
Active Work Time tracks only when the team is actively working, removing all waiting time from the cycle time. It accurately reflects the work required by the Engineering teams. (Active Work Time (NICE TO HAVE), p.4–5)How it's computed
Median of REAL hands-on time, shown in CALENDAR days: per workday, hours in non-passive statuses (capped at 8h) are summed, then ÷ 24. Weekends, the assignee's BambooHR vacations and country holidays contribute nothing. Same unit as Lead/Cycle — that's why active ≤ cycle always holds and the gap to Cycle IS the waiting. A full 8h work day shows as 0.3 d — small on purpose. Other units (working days, hours) are available via the unit switch/admin default.Example
5h Tue + 9h Wed (capped to 8h) + 3h Thu = 16h ÷ 24 ≈ 0.7 d of active work inside a 3-day cycle. Same ticket in other units: 2 wd · 16h.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →—d
Active Work Time tracks only when the team is actively working, removing all waiting time from the cycle time. It accurately reflects the work required by the Engineering teams. (Active Work Time (NICE TO HAVE), p.4–5)How it's computed
active_hours = Σ_workdays min(hours in non-passive statuses, 8h)
shown = active_hours ÷ 24 // unit: calendar days — same scale as Lead/Cycle, active ≤ cycle holds
passive = [On Hold, Blocked, Failed on QA, Ready To Test, Ready To Merge]
workday = weekday ∧ ¬assignee-vacation (BambooHR) ∧ ¬country-holidayThe numbers shownMedian of REAL hands-on time, shown in CALENDAR days: per workday, hours in non-passive statuses (capped at 8h) are summed, then ÷ 24. Weekends, the assignee's BambooHR vacations and country holidays contribute nothing. Same unit as Lead/Cycle — that's why active ≤ cycle always holds and the gap to Cycle IS the waiting. A full 8h work day shows as 0.3 d — small on purpose. Other units (working days, hours) are available via the unit switch/admin default.Example
5h Tue + 9h Wed (capped to 8h) + 3h Thu = 16h ÷ 24 ≈ 0.7 d of active work inside a 3-day cycle. Same ticket in other units: 2 wd · 16h.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →—d
≤ cycle · 8h/day cap · BambooHR
Time To First PR (median)iWhat it means
The Time to First PR measures the time between when a ticket was put in progress until an associated PR is opened. (Time To First PR (NICE TO HAVE, AI DRIVEN), p.5)How it's computed
Median days from work start to the FIRST linked PR opened at/after the start. “N PR” = measured tickets; “no PR” = done without any linked PR; “PR-before-start” = tickets whose only PRs predate the start — an anomaly, excluded from the median and disclosed.Example
Started Tue 09:00, PR mentioning the key opened Wed 15:00 → 1.2 d. If the only PR was opened on Monday (before the start) → anomaly bucket, not 0 days.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →—d
The Time to First PR measures the time between when a ticket was put in progress until an associated PR is opened. (Time To First PR (NICE TO HAVE, AI DRIVEN), p.5)How it's computed
ttfp = first(associated PR.created_at ≥ first(status of Jira category “In Progress”)) − first(status of Jira category “In Progress”) − Σ(time back in “new”-category statuses) // calendar days — weekends & holidays counted; same rules as Cycle Time
associated ⇔ PR title or source branch mentions the issue key
// only-earlier-PR tickets = anomaly bucket (excluded, disclosed) — spec M5 / T007The numbers shownMedian days from work start to the FIRST linked PR opened at/after the start. “N PR” = measured tickets; “no PR” = done without any linked PR; “PR-before-start” = tickets whose only PRs predate the start — an anomaly, excluded from the median and disclosed.Example
Started Tue 09:00, PR mentioning the key opened Wed 15:00 → 1.2 d. If the only PR was opened on Monday (before the start) → anomaly bucket, not 0 days.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →—d
—
Lead Time for Changes (median)iWhat it means
Lead Time for Changes measures the time it takes for a committed code change to successfully run in production. (Lead Time for Changes (DORA, NICE TO HAVE), p.5)How it's computed
Median days from the FIRST COMMIT of a merged PR to the first successful production deploy after the merge; “N changes” = merged PRs that reached production.Example
First commit Mon 10:00 → merged Wed → next successful prod deploy Thu 10:00 = 3.0 d.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →—d
Lead Time for Changes measures the time it takes for a committed code change to successfully run in production. (Lead Time for Changes (DORA, NICE TO HAVE), p.5)How it's computed
ltc = first(prod deploy after merge, result ∈ [succeeded]) − first_commit
prod ⇔ env name matches [production, prod, prd, live, stable] (lower tokens win first) // calendar days — weekends & holidays countedThe numbers shownMedian days from the FIRST COMMIT of a merged PR to the first successful production deploy after the merge; “N changes” = merged PRs that reached production.Example
First commit Mon 10:00 → merged Wed → next successful prod deploy Thu 10:00 = 3.0 d.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →—d
unavailable: needs merged PRs with first-commit data and recognizable production deploys
iWhat it means
Break down all Jira statuses from In Progress until it is done. (Status Breakdown (NICE TO HAVE), p.5–6)How it's computed
For every completed ticket, the time it sat in each status is summed up. “Days” = total days the whole cohort spent in that status; “Tickets” = how many tickets visited it. New-category statuses are shown but excluded from Cycle Time.Example
A ticket spent 2.0 d in In Progress and 1.5 d in Code Review → it adds those days to both statuses.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →
Break down all Jira statuses from In Progress until it is done. (Status Breakdown (NICE TO HAVE), p.5–6)How it's computed
For every completed ticket, the time it sat in each status is summed up. “Days” = total days the whole cohort spent in that status; “Tickets” = how many tickets visited it. New-category statuses are shown but excluded from Cycle Time.Example
A ticket spent 2.0 d in In Progress and 1.5 d in Code Review → it adds those days to both statuses.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →
Quality & Reliability
·Flow & Predictability
Bug Rate (environment unknown)
iWhat it meansThe Prod Bug Rate measures the number of bugs that were reported in the production environment, broken down per severity; Pre-Prod is the same for non-productive environments. (Prod Bug Rate (MUST HAVE) + Pre-Prod Bug Rate (NICE TO HAVE), p.6)How it's computed
bugs = count(type ∈ [Bug, Incident], created in window); rate = bugs ÷ weeks
severity = first present of [customfield_10050, customfield_10511, customfield_10093]
env: prod labels [production, prod] · pre-prod [pre-prod, preprod, pre-production, staging, qa] · none → unknownThe numbers shownCount of Bug/Incident tickets CREATED in the window · per-week rate · split by severity. The environment (prod / pre-prod) is read from ticket labels. When only SOME bugs are labeled, the headline is the labeled-prod count and the tile discloses the unlabeled remainder + coverage % — unknown bugs are never hidden.Example
4-week window with 12 bugs reported → 12 bugs · 3.0/week; a ticket labeled “production” would count as a prod bug.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.“Environment unknown”: the document defines Prod and Pre-Prod Bug Rates, and the environment is read from a label on the ticket. No bug in this window carries a recognized environment label, so the prod/pre-prod split would be a guess — instead the tile honestly counts ALL reported bugs and shows which labels would enable the split.Full rules, document text & live example →
0bugs · 0/weekΔ+0
— expected ticket labels: production, prod (prod) · pre-prod, preprod, pre-production, staging, qa (pre-prod) configurable →
Pre-Prod Bug Rate
iWhat it meansThe Prod Bug Rate measures the number of bugs that were reported in the production environment, broken down per severity; Pre-Prod is the same for non-productive environments. (Prod Bug Rate (MUST HAVE) + Pre-Prod Bug Rate (NICE TO HAVE), p.6)How it's computed
bugs = count(type ∈ [Bug, Incident], created in window); rate = bugs ÷ weeks
severity = first present of [customfield_10050, customfield_10511, customfield_10093]
env: prod labels [production, prod] · pre-prod [pre-prod, preprod, pre-production, staging, qa] · none → unknownThe numbers shownSame as Bug Rate but only bugs whose ticket carries a PRE-PROD environment label (caught before production — the earlier the cheaper).Example
12 bugs in the window, 7 labeled “staging” → Pre-Prod Bug Rate = 7; the other 5 belong to prod or unknown.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.“Environment unknown”: the document defines Prod and Pre-Prod Bug Rates, and the environment is read from a label on the ticket. No bug in this window carries a recognized environment label, so the prod/pre-prod split would be a guess — instead the tile honestly counts ALL reported bugs and shows which labels would enable the split.Full rules, document text & live example →
—
unavailable until tickets carry environment labels — expected ticket labels: pre-prod, preprod, pre-production, staging, qa configurable →
Change Failure Rate
iWhat it meansCFR measures the percentage of software deployments to production that result in a degraded service and require immediate remediation. (Change Failure Rate (MUST HAVE, DORA), p.6–7)How it's computed
cfr = failed ÷ eligible_production_deploys × 100 // eligible = result ∈ success ∪ failure; canceled/notDeployed excluded
failed ⇔ result ∈ [failed] ∨ manual flag // bridge until Incident ManagementThe numbers shown% = failed ÷ ELIGIBLE production deploys × 100. “N failed / M” under the % shows both counts. Eligible = succeeded or failed only — canceled/notDeployed runs never reached production and are excluded (disclosed when present). The flag button manually marks a deploy as a failure (rollback/hotfix bridge until Incident Management).Example
Window has 40 succeeded + 2 failed + 3 canceled prod runs → eligible = 42, CFR = 2 ÷ 42 = 4.8% (the 3 canceled don't dilute it).The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →
—
failed production deployments / total production deployments × 100. A failure today = pipeline result “failed” or a manual flag — the bridge until Incident Management (P0/P1 rollback/hotfix) is integrated.
Deployment Frequency
iWhat it meansThe Deployment Frequency measures how often a team/project successfully releases code to the production environment — total plus Daily / Weekly / Monthly rates. (Deployment Frequency (MUST HAVE, AI DRIVEN), p.7)How it's computed
df = count(prod deploys, result ∈ [succeeded])
rates: ÷ days · ÷ weeks · ÷ (30-day months)The numbers shownSuccessful PRODUCTION deploys in the window, plus Daily / Weekly / Monthly rates (month = 30 days). Runs whose environment tier can't be recognized are disclosed separately, never silently dropped.Example
21 successful prod deploys in a 7-day window → 3.0/day · 21.0/week · 90/month.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →
—
environment tier unrecognizable — 0 successful deploys across all environments
Throughput
iWhat it meansThe Throughput should measure the number of completed tickets within a timeframe as well as the average number of completed tickets per week. (Throughput (MUST HAVE, AI DRIVEN), p.7)How it's computed
throughput = count(done in window) ; per_week = count ÷ weeks
split: assignee ∈ AI agent roster → agent, else humanThe numbers shownTickets that ENTERED a done status inside the window (last such entry; Epics excluded) · per-week rate · split into AI agents / humans by the assignee roster.Example
30 tickets done in the window, 4 assigned to AI agents → 30 total · agents 4 / humans 26.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →
0tickets · 0/weekΔ+0
agents 0 · humans 0
Planned vs Unplanned
iWhat it meansMeasures how the flow of a team can be impacted by unexpected work; the classification depends on whether the team reserves maintenance capacity. (Planned vs Unplanned Work (MUST HAVE), p.8)How it's computed
unplanned ⇔ type ∈ [Bug, Incident] ∨ label ∈ [unplanned_work]The numbers shown% = unplanned ÷ all completed × 100; “P / U” = planned and unplanned counts. Unplanned = Bug/Incident type OR the unplanned_work label (when the team reserves capacity for bugs, only the label counts).Example
30 done tickets, 6 are Bug/Incident or labeled unplanned_work → unplanned 20%.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →
—0 / 0
Bug/Incident ∨ unplanned_work
PR Throughput
iWhat it meansPR Throughput = merged PRs within a timeframe plus the average merged per week; PR Acceptance Rate = merged vs abandoned. (PR Throughput + PR Acceptance Rate (NICE TO HAVE, AI DRIVEN), p.8)How it's computed
pr_throughput = count(merged in window) ; per_week = merged ÷ weeks
acceptance = merged ÷ (merged + abandoned) × 100The numbers shownPRs MERGED in the window · per-week rate; “abandoned → accepted %” = merged ÷ (merged + abandoned). Open PRs are not counted until they close.Example
25 merged + 5 abandoned in the window → 25 merged · acceptance 25 ÷ 30 = 83.3%.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →
0merged · 0/weekΔ+0
0 abandoned → — accepted
AI Participation Rate
iWhat it meansThe AI Participation Rate should measure the percentages of tickets done that had an AI Agent Assigned. (AI Participation Rate (NICE TO HAVE, AI DRIVEN), p.8)How it's computed
participation = count(done ∧ assignee ∈ AI agents) ÷ count(done) × 100The numbers shown% = completed tickets assigned to AI agents ÷ all completed × 100; “A / T” = both counts. Same cohort as Throughput — the numbers always reconcile.Example
4 of 30 done tickets are assigned to AI agents → 13.3%.The gray Δ chip next to the value = change vs the PREVIOUS window of the same length (these 90 days vs the 90 before them, etc.). Gray on purpose: the direction is not judged — a lower Lead is good, a lower Throughput is not — read it as context, never as a score.Full rules, document text & live example →
—0 / 0
tickets done with an AI agent assigned