Chronic Regression - 3,403 Tickets, 12-Day Re-Emergence Median
Measure re-emergence, not close rate
Teams celebrate closure rates. Users see the same defect class again in about twelve days. On a multi-system launch I lead, Jira looked healthy week over week - then registration, identity, and UI clusters reopened faster than a sprint could absorb the "done" work.
Here's what this piece covers: why close rate lies, what the 2026-07-13 recurrence report measured, how we cluster and git-link signatures, the named pattern, and three habits that stop ticket whack-a-mole. Companion to spread triage - same leverage idea on production defects.
Part of the Field Notes: agentic delivery series.
1. The leadership problem
Defect intake stays high even when tickets close. Standups report velocity. Two weeks later the same seam fails - entitlement after confirm, identity after bind, card UI after a content package ship.
Wrong: "We closed 3,403 tickets."
Right: "Median 12-day re-emergence across 185 events - here is how we linked signatures to root-cause IDs and source areas."
The anti-pattern is ticket whack-a-mole - velocity without recurrence tracking. Closing a row is not owning a problem class.
2. What the analysis shows
Data fetched 2026-07-13 into analysis/regression/regression-summary.md (GLSCM + PTC created in 2026; git mined from the three delivery repos):
| Metric | Value | Confidence |
|---|---|---|
| Tickets analyzed | 3,403 | Verified (fresh Jira fetch) |
| Git-linked tickets | 878 | Verified (~74% lack links → under-count) |
| Problems with re-emergences | 54 | Verified |
| Re-emergence events | 185 | Verified |
| Median days to re-emerge | 12 | Verified (mean 19.9) |
| Chronic problems | 33 | Verified (≥2 in 60 days, or recent re-open) |
Interval buckets: 63 events in 0–7 days, 78 in 8–30, 40 in 31–90, 4 at 90+. Twelve days is faster than most sprint cadences - continuous targeting beats backlog grooming alone.
3. What I built
A recurrence pipeline, not a one-off spreadsheet:
Cluster tickets by problem signature and source area (Jira links, shared git code area + similarity, then summary similarity).
Detect re-emergence when ticket A has a merged fix and ticket B in the same cluster is created after that merge - one event per qualifying pair.
Attribute source areas from git path buckets first, then cluster git, workflow area, keywords, team fallback.
Top chronic by re-emergence count: Hero/Card UI cluster (29), Registration UX + warranty / Q1 launches mega-cluster (27), Search config + i18n event-details (13). Source-area heat: Hero/Card UI 54, Search + i18n 44, Registration UX + warranty 36, UUP identity 16.
def is_chronic(problem, *, window_days=60, recent_days=30):
gaps = problem.reemergence_gaps_days
if sum(1 for g in gaps if g <= window_days) >= 2:
return True
return any(g <= recent_days for g in gaps[-3:]) # recent reopenThe Confluence metrics draft (2026-07-28) puts this on a causal chain: delivery dashboard → visibility → recurrence targeting → burn-down. This article is the middle link.
4. Named pattern: chronic regression
Chronic regression - measure re-emergence (median gap and event count), not just close rate; link signatures to root-cause IDs and source-area owners.
| Artifact | Who uses it | Decision it supports |
|---|---|---|
| Recurrence summary | EM, leads | Which problem classes to staff |
| Source-area heat | Team leads | Who owns the seam, not the ticket |
| Git-link rate | Platform | Where detection under-counts |
| Chronic list (33) | Sprint review | Separate review from backlog grooming |
What broke: fixing symptoms without seam ownership → same class returns inside two weeks. Mega-clusters (e.g. Q1 Launches, 383 tickets) can over-merge distinct issues - use team/theme/area breakdowns before assigning one owner to everything. Recurrence is under-counted when tickets lack git links.
5. What I'd do as a lead
Three habits - steal one this month:
- Run a weekly chronic-problem review separate from sprint grooming. Close rate is a vanity metric; the 33 chronics are the agenda.
- Assign an owner per source area, not per ticket. Hero/Card, Registration + warranty, Search + i18n, identity - one name each.
- Pair production recurrence with test spread triage. Same leverage math: 393 → 27 by context spread for E2E; this pipeline for Jira reopen classes.
Further reading
- Field notes: agentic delivery - series intro
- Prior: 393 failures, 27 root causes
- Next: Outcome-aligned teams
- Related: Engineering delivery dashboard
- Planning anchor: regression summary · 2026-07-13
