Both teams, same rules, same window — the document's standardization goal is exactly this comparability. Numbers are reported side by side without judgement.
| Metric | ADS ↗ | EVO ↗ |
|---|---|---|
| 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 lead = done_at − created_at // calendar days — weekends & holidays countedThe 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.Full rules, document text & live example → | — 0 tickets | — 0 tickets |
| 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 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)The 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.Full rules, document text & live example → | — | — |
| 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 active_hours = Σ_workdays min(hours in non-passive statuses, 8h)The numbers shownMedian of REAL hands-on time, shown in RAW HOURS: per workday, hours in non-passive statuses are summed with the 8h/day cap; weekends, BambooHR vacations and country holidays contribute nothing. The unit with zero ambiguity (the manager: "amount of hours or amount of days of effective active work"). Mental math: ÷ 8 ≈ working days, ÷ 24 ≈ calendar days.Example 5h Tue + 9h Wed (capped to 8h) + 3h Thu = 16h. Same ticket in other units: 2 wd · 0.7 d (calendar). Saturday hours would add nothing (non-working day).Full rules, document text & live example →cal. dayswork days°hours | — | — |
| 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 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 TimeThe 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.Full rules, document text & live example → | — | — |
| 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 ltc = first(prod deploy after merge, result ∈ [succeeded]) − first_commitThe 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.Full rules, document text & live example → | — | — |
| ThroughputiWhat it means The 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 ÷ weeksThe 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.Full rules, document text & live example → | 0 0/week · agents 0 / humans 0 | 0 0/week · agents 0 / humans 0 |
| Planned vs UnplannediWhat it means Measures 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%.Full rules, document text & live example → | — 0 planned / 0 unplanned | — 0 planned / 0 unplanned |
| Bug Rate (all reported)iWhat it means The 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 ÷ weeksThe 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.Full rules, document text & live example → | 0 0/week · environment unknown | 0 0/week · environment unknown |
| Deployment FrequencyiWhat it means The 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])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.Full rules, document text & live example → | — | — |
| Change Failure RateiWhat it means CFR 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 excludedThe 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).Full rules, document text & live example → | — | — |
| PR ThroughputiWhat it means PR 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 ÷ weeksThe 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%.Full rules, document text & live example → | 0 0/week · — accepted | 0 0/week · — accepted |
| AI Participation RateiWhat it means The 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%.Full rules, document text & live example → | — 0 / 0 | — 0 / 0 |