Business Area — a small item and a large one move the average the same amount. "Under Review" items score 0% (built/submitted, not yet advanced by review) — an area at/near 0% usually means "mostly awaiting review," not "nothing started." See Calculation Rules.rules/governance_thresholds.yaml; changing a value there changes the dashboard immediately.Two panels were removed entirely rather than kept as mock placeholders, since neither has a real Jira data source and none is foreseeable:
Primary (feature) teams — 9 teams, shown on Program/Product Management and rolled up org-wide on Executive Overview: MVP Team A, MVP Team B, Omega, Omega Team B, Nexus, Vertex, Pulse, Synapse (Platform Innovation Teams), Program Enhancement. Support team — Production Support — has no dedicated tab; still folded into Executive Overview's org-wide numbers. 9 other EP boards are out of scope entirely (see rules/ep_boards.yaml).
Same formula as the team-level Defect Leakage % below, aggregated across all 9 feature teams and Production Support.
Changed 2026-08-25 to the same Reported By field and issue set as Defect Leakage % below — no longer the Environment field. Shows a real count for each of the 5 actual dropdown values (Dev, QA, Product, Operations, Production Support), plus an Unclassified slice for blank/unset Reported By. Fully real — no mock slice.
Changed 2026-08-25 to a team-supplied JQL, run project-wide (not scoped to the 8 dashboard boards — the supplied query has no board/team filter): Bug/Task tickets, status not Withdrawn, Environment = Production, Client Impact in {NovoCare, All Clients, Teva Cares, TEVA Cares, Teva Shared Solutions}, priority P1–P4, summary not matching "datadog", created this calendar month vs. last. See rules/governance_thresholds.yaml::exec_overview.production_bugs for the exact list.
Changed 2026-08-25, same pattern as Production Defects above but keyed on the real Incident Severity field: Bug/Task tickets, status not Withdrawn, Environment = Production, Incident Severity = "Sev-1 Critical - System unusable", summary not matching "datadog", created this month vs. last — project-wide. Previously an approximation via ticket Priority; this is the actual severity classification instead. See rules/governance_thresholds.yaml::exec_overview.critical_incidents.
Count of tickets in the literal Jira status Blocked, across the 9 feature teams' active sprints. "Aged" = idle 3+ days. Reported as a plain count — Jira has no cause/category taxonomy for blockers, so no breakdown is shown as real (see the mock callout above for the illustrative split).
For tickets across the 9 feature teams + Production Support that entered a release-ready status in the last 30 days: median working days (Mon–Fri) between a ticket's first entry into In Progress/Under Development and its first entry into Ready for Release/Assigned to UAT. Only the first pass is measured — a ticket that re-enters development after reaching a release-ready status isn't re-measured.
Scope: tickets labeled RMV1. Progress % comes from each item's own current status. Updated 2026-08-26 (team-supplied new formula): Open, Under Development, Development Finished, Assigned to QA, and QA Successful lowered; Ready For UAT added as a new status. Assigned to UAT/Done/Closed/Resolved weren't part of the new table and stay at 100% (unchanged) rather than dropping to no data.
| Status | Progress % |
|---|---|
| Open | 5% |
| Under Development | 20% |
| Development Finished | 40% |
| Under Review | 0% |
| Assigned to QA | 50% |
| Assigned to UAT | 100% |
| Ready For UAT | 75% |
| QA Successful | 75% |
| Ready for Release / Done / Closed / Resolved | 100% |
A status not in this table shows "—". The portfolio average excludes Not Started items. Health, evaluated top to bottom, first match wins: (1) Later label → Not Started (excluded from the average); (2) status QA Successful/Ready for Release/Assigned to UAT → On Track (even if overdue — Assigned to UAT added 2026-09-08, team request); (3) due date in the past and not complete → Off Track; (4) else the Delivery Confidence field: On Track/Delivered → On Track, Watch → At Risk, unset → TBD.
Changed 2026-08-25 (team-supplied JQL) from mock placeholders to real data, using the exact same status-progress-pct lookup and health waterfall above, each scoped to a different label: Nursing → labels IN (NursingV1), PAP → labels IN (PAPV1), Reimbursement + Common → reuses the RMV1 roadmap result directly above (same query, no separate fetch). See rules/governance_thresholds.yaml::roadmap.capability_bundles.
The "Capability Roadmap Progress" 3-line chart underneath these cards is also real as of 2026-08-25 — each bundle's items have their full Jira status-change history walked once and reconstructed as of the last 6 real sprint-end dates (same technique the RMV1 Rolling Sprint Trend already used, generalized to all 3 bundles — see _compute_capability_bundle_trend). Caveat carried over from that mechanism: the "Later" (Not Started) exclusion uses each item's current labels, not its labels as of each past checkpoint, and an item's status before its own creation date is inferred from its earliest recorded transition rather than excluded — a newly-created bundle (e.g. Nursing, 5 items) can show flat/low values across every historical point as a result.
Added 2026-08-25 (team request) — a breakdown of the RMV1 roadmap items above by their Business Area field (customfield_11089), on Executive Overview. Each item's completion % is the same status lookup above; items are grouped by Business Area and averaged with equal weight per item, regardless of size — a small item and a large one move an area's average by the same amount, so this reflects how many of an area's items are advanced, not how much engineering effort is done. Under Review items count as 0% — built and submitted, but contributing nothing to the area's % until review moves them forward; an area at/near 0% typically means "mostly awaiting review," not "nothing has started." Not Started (Later-labeled) items are excluded from the average, same as the overall RMV1 KPI. A multi-valued Business Area counts the item once toward each area listed.
Added 2026-09-10/11 (RM_V1_Epic_Metrics_Audit_With_Rules V2.xlsx) — this replaced a badge left blank on 2026-09-08 pending a team decision on what should roll up into it. 3 milestones, each targeting 100% of the 43 in-scope RM V1 epics, tracked in parallel from a shared start date of Aug 10, 2026:
QA Successful or Assigned to UAT or later (achievement counts from QA Successful onward).Ready for Release or later.Done/Closed/Resolved.Per milestone: Achievement % = epics whose Actual Completion % is at or beyond the required status's own value in the shared status→% table above ÷ 43. Time Elapsed % = calendar days from Aug 10 to today (capped at the milestone date) ÷ total calendar days Aug 10 → the milestone date. Pace Variance = Achievement % − Elapsed %, in percentage points. Health: 🟢 On Track (variance ≥ 0) · 🟡 At Risk (1–10 points behind) · 🔴 Off Track (more than 10 points behind).
The Executive "OVERALL DELIVERY HEALTH" badge is the worst-of the 3 milestones' health — Off Track if any milestone is Off Track, else At Risk if any is At Risk, else On Track — replacing, not combining with, the portfolio/leakage/blocker/roadmap signals that badge used before it was blanked (those still show on their own cards).
Added 2026-09-02, revised 2026-09-03 three times — first against a "canonical v3" product-team spec (Actual % switched from a binary Done-child ratio to an SP-weighted credit scale; per-epic Expected%/Variance window switched to Due Date); then the release-level window (Schedule Elapsed %, Ideal/Actual Burn) briefly switched to UAT Date, not Due Date — "take UAT date which is last for an epic"; then again same day per direct team request: that release-level window became a hardcoded, fixed date range (originally Aug 10 → Oct 31, 2026) instead of being derived from any epic's own dates at all — the data-driven version reshuffled, and could flip who read "ahead"/"behind," every time an epic's dates changed, and was skewed by outlier epics (e.g. EP-1128, a Start Date 2 months earlier than any other epic). Due Date stays the basis for each epic's own Expected%/Variance below — only the release-wide headline is now fixed. End date changed 2026-09-15 to Oct 19, 2026 (start date unchanged) — see below. See rules/governance_thresholds.yaml::rmv1_release_plan.release_window.
Delivered / Low — Delivery Confidence = Delivered is included in completion buckets but excluded from AI Estimated Effort and SP Burn Detail. Delivery Confidence = Low is excluded from AI Estimated Effort and completion buckets (Epic Health / Epic Breakdown still show those epics).
Completion Buckets — every in-scope epic (Delivered included, Low excluded) is classified by its own status (not its children's) into one of four buckets, weighted by Estimated Efforts (Engineering Effort only — blank contributes 0):
Ready for Release, Assigned to UAT, Done.QA Successful.Assigned to QA, In QA, Development Finished, Under Development, Feedback to Dev.Under Review, Open, DESIGN REVIEW.Headline numbers: SOW Effort = hardcoded baseline (2132). AI Estimated Effort = sum of Engineering Effort excluding Delivery Confidence = Delivered and Low. Consumed + Booked Effort = sum of each epic's Actual Efforts (Story Points already consumed plus still booked on Story+Bug+Task children), same Delivered/Low exclusion. Schedule Elapsed % = working days elapsed ÷ the fixed release window (Aug 10 → Oct 19, 2026, minus holidays). Each bucket shows % = bucket effort ÷ bucket total (Delivered included).
Per-epic detail (on the Epic Breakdown table below) — revised 2026-09-10/11 (RM_V1_Epic_Metrics_Audit_With_Rules V2.xlsx):
Open/To Do/Under Review/Blocked 0% · In Progress/Under Development 25% · Development Finished/Feedback to Dev 50% · Assigned to QA/In QA 75% · QA Successful/Assigned to UAT/Ready for Release/Done 100%. An epic with zero Story/Bug children falls back to its own status→% lookup (see Roadmap Progress) rather than showing no value. Reverted 2026-09-12 (team clarification) — between 2026-09-10 and 2026-09-12 this was a direct lookup of the epic's own current status instead; before 2026-09-10 it was this same children-weighted idea but SP-weighted, not equal-weighted.Health (renamed from "Release Status" 2026-09-11; Schedule Health only — first match wins):
Bug Ratio and Effort Ratio (below) do not fold into this Health value — team request 2026-09-11 dropped that precedence-combine (briefly implemented 2026-09-10/11) in favor of keeping each as its own independent column/chip.
SP Burn Detail — the release-level window is the hardcoded, fixed range Aug 10 → Oct 19, 2026 (not derived from any epic's own dates), excluding epics already marked Delivered (buckets include them; AI Estimated Effort excludes Delivered and Low). Scope per epic = Estimated Efforts, falling back to Actual Efforts only when Estimated is blank. Ideal Burn SP = this section's Total Scope × the fixed window's elapsed %. Actual Burn SP = sum of each non-Delivered epic's Actual % × its scope. Gap = Actual − Ideal, shown in SP and %.
Added 2026-08-31 (Meghan, feedback call): "a full list of every single epic... how many stories, how many bugs... story pointed... aligned with the original estimate." Every RM V1 item of issue type Epic (including Delivery Confidence = Delivered), with a batched query for its direct children — Story/Bug/Task (Sub-task excluded; Withdrawn excluded). Actual Efforts / Actual % use Story+Bug+Task; Stories/Bugs columns and Bug Ratio stay Story/Bug only. Column headers (except Epic) are sortable; a filter row supports dropdowns on categorical columns and text match on numeric ones.
Estimated Efforts / Actual Efforts / Ratio — added 2026-09-03, correcting an earlier claim (2026-08-31, re-checked 2026-09-02) that no epic-level estimate field exists. That check searched field names for "estimate"/"story point" and missed Engineering Effort, which matches neither keyword — verified live 2026-09-03: populated on all 43 RM V1 epics. Estimated Efforts = that field, direct pull ("no estimate set" when blank, not 0). Actual Efforts = Σ Story Points across the epic's Story+Bug+Task children (Task added 2026-09-23; Sub-tasks still excluded). Ratio (Effort Ratio) = Actual ÷ Estimated.
Bug Ratio (added 2026-09-10/11) = Bugs ÷ (Stories + Bugs), per epic. 🟢 <20% Healthy · 🟡 20–34.9% Moderate · 🔴 ≥35% Poor, plus a Critical escalation badge at ≥50% shown alongside the chip. Its own independent column — as of 2026-09-11 it no longer feeds into the epic's Health column (see RM V1 Release Plan).
Effort Ratio (added 2026-09-10/11) — same value as the Ratio column above, labeled ≤0.90 Under Estimate · 0.90–1.10 Aligned · >1.10–1.30 Elevated · >1.30 Significantly Elevated. A low ratio isn't automatically "good" — an early-lifecycle epic can read low simply because the work isn't done yet. Shown as its own label next to the Ratio column — as of 2026-09-11 it no longer feeds into the epic's Health column (see RM V1 Release Plan).
Scope Change. Today's Stories/Bugs/Story Points vs. each epic's earliest recorded daily snapshot (memory/epic_history.json), added 2026-08-31 — this tracks day-over-day drift in the children's own totals, a different question from the Estimated-vs-Actual-Efforts snapshot above. Shows "Collecting data" until 2+ days of history exist for that epic, the same way the daily trend charts on Executive Overview needed 2+ days before they showed anything real.
Added 2026-09-23 — same release-plan / epic-breakdown / schedule-health / bug-ratio / effort-ratio rules as RM V1 above, scoped to tickets labeled Epysqli_Migration via JQL labels = Epysqli_Migration ORDER BY "cf[11435]" ASC, "cf[10001]" ASC, created DESC (see Jira filter). Config: rules/governance_thresholds.yaml::epysqli_migration.
Release window seeded from live Jira as Sep 18 → Nov 2, 2026 (first ticket created dates + UAT Date on sampled epics). SOW Effort is unset until the team supplies a baseline (shows —). Scope-change history lives in memory/epic_history_epysqli.json (separate from RM V1's epic_history.json).
Added 2026-09-23 — same release-plan / epic-breakdown rules as RM V1 / Epysqli, scoped to tickets labeled Biogen_Migration via JQL labels = Biogen_Migration ORDER BY "cf[11435]" ASC, "cf[10001]" ASC, created DESC (see Jira filter). Config: rules/governance_thresholds.yaml::biogen_migration.
Release window seeded as Sep 18 → Nov 2, 2026. SOW Effort unset until the team supplies a baseline. Scope-change history: memory/epic_history_biogen.json.
Straight averages of the 4 metrics below across the 9 primary teams. Teams with no data for a metric (e.g. no active sprint) are excluded from that average, not counted as 0.
Done SP ÷ Total SP × 100, straight from Jira's own Sprint Report (/rest/greenhopper/1.0/rapid/charts/sprintreport — jira.py::get_sprint_report) — switched 2026-09-04 from a hand-maintained "done" status-NAME list applied to a live sprint = X JQL scan. Team-reported discrepancy: MVP A read 56% here vs 63% on Jira's own Sprint Report; MVP B read 47% vs 74%. Root cause: the old status list (QA Successful, Ready for Release, Done, Closed, Resolved) was missing Assigned to UAT — a status Jira's own workflow puts in the Done category, which its Sprint Report already accounts for correctly. Same class of bug Carry-over % below hit and fixed 2026-08-25 the same way. Falls back to the old live-scan number only if the Sprint Report call itself fails.
Scoped 2026-08-27 (team request, confirmed against a discrepancy with a spreadsheet-based dashboard) to issue types Story, Task, Bug only — Sub-tasks and Epics are excluded entirely from both sides of the ratio. Sub-tasks in this Jira instance often carry their own story points and get closed out independently of their parent Story, which was inflating done_pct beyond what a story-level-only view shows (verified live: one active sprint read 17% including Sub-tasks, 7% Story/Task/Bug only). Tickets in status Withdrawn are also excluded entirely (never real work). This scoping still governs the P1/P2 and unassigned counts below, which are computed from the live scan (not the Sprint Report) — only the headline Done SP ÷ Total SP ratio switched sources. See jira.py::_compute_board_metrics.
Health changed 2026-08-25 (team request) from a flat end-of-sprint bar to a pace-relative one — the old bar (green ≥80%, red <60% of raw done_pct) meant every team read red on day 1 of a fresh sprint almost by construction, regardless of real pace. Now: for the first min_elapsed_days_for_health working days of the sprint (5, changed 2026-08-26 from a 20%-of-sprint-length grace period — a % grace period gave a short sprint only a day or two before scoring kicked in), health is No Data — too early to assess. After day 5, pace_ratio = done_pct ÷ time_elapsed_pct: 🟢 >0.80 · 🟡 0.60–0.80 · 🔴 <0.60. See rules/governance_thresholds.yaml::sprint_completion_pct.
Any "done" ticket with no story-point estimate is invisible to this ratio — the dashboard surfaces the count and keys as a caveat on the pod card rather than guessing a value. Scoped to Story/Task only, EXCLUDING Bug — narrowed 2026-09-14 (team request: "It should consider only story+task and exclude Bugs"), a further narrowing on top of the Story/Task/Bug scope above (Sub-tasks — which frequently have no points of their own since points live on the parent — were already excluded and still are).
On the team's most recently closed sprint: (Total SP − Done SP) ÷ Total SP × 100. Same "Done" statuses as Sprint Completion % above — mostly QA Successful in practice, not literal Jira "Done."
Threshold: 🟢 ≤10% · 🟡 10–20% · 🔴 >20%
Every closed-sprint metric on this dashboard (Carry-over %, Portfolio Sprint Delivery Trend, Pod Velocity Trend, Pod Delivery Performance) is pulled from Jira once, the first time a sprint is detected as closed, and stored as an immutable snapshot in memory/governance_sprint_history.csv — by design. Jira sprint data keeps changing after a sprint closes (issues get punted or edited retroactively), so a live Jira gadget covering the same sprints can show slightly different numbers depending on when it's viewed; this dashboard's trend is anchored to the sprint's state at close, not to whatever it drifts to afterward. See governance.py::_record_sprint_history.
Changed 2026-08-25 from an Environment-field (where found) basis to a Reported By (who found it) basis: Leaked ÷ (Leaked + Caught) × 100, for Bugs created this calendar month on that team's board.
Reported By (customfield_10554) bucket: Product, Operations, Production Support → Leaked; Dev, QA, or blank/unset → Caught. A future dropdown value not in either list is excluded from both sides. See rules/governance_thresholds.yaml::reported_by_buckets.
Excluded entirely (both sides): tickets in status Withdrawn — never a real defect. Done, Closed, and Resolved bugs all count — those are real, fixed defects. See defect_leakage_pct.excluded_statuses.
Threshold: 🟢 ≤10% · 🟡 10–20% · 🔴 >20%
(Added tickets + Modified tickets) ÷ Total tickets in sprint × 100.
Counted by ticket count, not story points. Does not cover Removed scope (a ticket pulled out of the sprint before it finished).
Scoped to Story only (narrowed 2026-09-04, team request: drop Bugs from scope — a Bug's own scope isn't a requirements-volatility signal the way a Story's is; itself narrowed from Story/Bug 2026-09-03, which had narrowed from Story/Task/Bug the same day — focus on Story, not Task/Sub-task/Bug), Withdrawn excluded. See governance.py::_compute_requirements_volatility.
Threshold: 🟢 ≤10% · 🟡 10–20% · 🔴 >20%
Drill-down (added 2026-09-03) — clicking the number shows each affected ticket's Reason (Added, Modified: Description, Modified: Acceptance Criteria, or both), not just a flat key list. The Type column (Story/Bug) from when Bugs were still in scope is still shown but will only ever read Story now.
Majority rule across Sprint Completion, Carry-over, and Scope Churn % health — changed 2026-09-04 (team request: a single worst-of red made the whole card read red even with the other two metrics green, "sounds unfair" to the team). 2 of the 3 metrics red escalates the card to red; a single red metric downgrades the badge to amber instead. Amber is not majority-gated the same way — one amber among two greens still reads amber, same as before, since the fairness complaint was specifically about red dominating. Each metric's own chip on the card still shows its individual color regardless of this badge — nothing is hidden, only the headline judgment is softer. Defect Leakage removed from this per-team rollup 2026-08-26 (team request) along with its card — still real and shown at the portfolio/exec level (Portfolio Delivery Metrics, Executive Overview).
For Stories that reached QA Successful in the last 30 days: median working days from first entry into In Progress/Under Development to first entry into QA Successful, bucketed by story points. Expected days = story points × 1 working day/point.
Added 2026-08-31 (Neelu/Meghan, feedback call). Neelu: "UAT of a ticket cannot be a parameter to calculate end-to-end cycle time because we have planned releases... shouldn't it be QA Successful? Or we need to add more... numbers." Meghan: the Executive Overview metric stays UAT-based (a planned/batched release insulates from "won't reach Done mid-sprint"), but at team/detail level ("not at the executive level, but for our own level") the same tickets and window get broken into phases, using first-entry-into-status timestamps, same technique as End-to-End Cycle Time and Estimation Reliability above:
In Progress/Under Development) → Assigned to QA.Assigned to QA → QA Successful.QA Successful → Assigned to UAT (the executive metric's own end status).QA Successful, a second end-to-end number alongside the UAT-based executive one, exactly what Neelu asked for.A phase needs at least 2 samples to report a median — one data point isn't a meaningful "median." A ticket missing a phase boundary (e.g. it skipped Assigned to QA) just drops out of that one phase's sample, not the others.
Rework ("what's that swirl inside," Meghan) — % of the window's tickets that entered Feedback to Dev at least once, and the total count of bounce-backs across them (every re-entry counted, not just the first — see jira.py::get_status_transitions, a variant of the first-entry-only helper the other cycle time metrics use).
No reliable Jira data source exists for these — shown nowhere as real data, rather than fabricated:
| Metric | Why |
|---|---|
| Delivery Defect Rate | No field ties a delivered story to the defects it caused. |
| Release Artifact Timeliness / Artifact Acceptance w/o Rework | No release-artifact tracking in Jira. |
| Scope Churn % — Removed scope | A ticket pulled out of a sprint isn't in its issue list anymore, so it can't be detected this way. |
| Release / Milestone Predictability | No release/milestone-date tracking in Jira. |
| Quality Gate Performance (QA First-Pass, UAT First-Pass rate, Product Validation pass rate) | No rework/reopen field to compute a first-pass rate from, on any board. Removed from the dashboard 2026-08-26 rather than shown as mock. |
| Actions / Decisions Needed, Release / Milestone Detail | No such workflow or date field exists in Jira. |
| Delivery Capacity Trend | No per-sprint completed-points history is tracked for this specific view. (Pod Velocity Trend and Pod Delivery Performance are both real as of 2026-08-25/26 — see Program/Product Management.) |
| Blockers by Cause taxonomy | Only a raw "Blocked" status count exists; no cause/category field or label convention. Removed from the dashboard 2026-08-26 rather than shown as mock; the real total blocked count still feeds Critical Blockers on Executive Overview. |
Full historical detail, resolved bugs, and open leadership sign-off questions: docs/governance_dashboard.md.