> ## Content Index
> Fetch the complete content index at: https://contextfirst.blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Chronic Regression - 3,403 Tickets, 12-Day Re-Emergence Median
- URL: https://contextfirst.blog/chronic-regression-3403-tickets/
- Published: 2026-09-16T13:00:00.000Z
- Updated: 2026-09-16T13:00:00.000Z
- Description: Measure re-emergence, not close rate
- Author: Iheatu Chris Wogu
- Tags: Field Notes, Engineering Management, Agentic Delivery, Learning Journey 2026

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](https://contextfirst.blog/spread-triage-393-to-27/) \- same leverage idea on production defects.

Part of the [Field Notes: agentic delivery](https://contextfirst.blog/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.

flowchart LR T\[3403 tickets\] --> C\[Cluster by signature\] C --> G\[Git-link when present\] G --> E\[Re-emergence events\] E --> M\[Median gap = 12 days\] E --> H\[Chronic = 33 problems\] H --> S\[Source-area owners\]

---

## 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**.

```python
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 reopen
```

The Confluence metrics draft (2026-07-28) puts this on a causal chain: [delivery dashboard](https://contextfirst.blog/engineering-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:

1. **Run a weekly chronic-problem review separate from sprint grooming.** Close rate is a vanity metric; the 33 chronics are the agenda.
2. **Assign an owner per source area, not per ticket.** Hero/Card, Registration + warranty, Search + i18n, identity - one name each.
3. **Pair production recurrence with test spread triage.** Same leverage math: [393 → 27 by context spread](https://contextfirst.blog/spread-triage-393-to-27/) for E2E; this pipeline for Jira reopen classes.

---

### Further reading

- [Field notes: agentic delivery](https://contextfirst.blog/field-notes-agentic-delivery/) \- series intro
- Prior: [393 failures, 27 root causes](https://contextfirst.blog/spread-triage-393-to-27/)
- Next: [Outcome-aligned teams](https://contextfirst.blog/outcome-aligned-teams-journeys/)
- Related: [Engineering delivery dashboard](https://contextfirst.blog/engineering-delivery-dashboard/)
- Planning anchor: regression summary · 2026-07-13

---

![Iheatu Chris Wogu](https://avatars.githubusercontent.com/u/3457705?s=176&v=4)

## About the author

**Iheatu Chris Wogu** is an engineering manager focused on launch programs, honest engineering metrics, and **engineering-led, agent-accelerated** delivery - researching where work queues up when agents widen dev output, then building proof, gates, and measurement that scale.

Field notes live on [First Context](https://contextfirst.blog/). Values treatise: [engineering manager values](https://contextfirst.blog/engineering-manager-values/).

**LinkedIn:** [linkedin.com/in/iheatu-chris-wogu](https://www.linkedin.com/in/iheatu-chris-wogu/?ref=contextfirst.blog)