Post-Release & Learning · master area
Bug Filing & Triage
Six dimensions. Daily for the first week post-release; twice-weekly after. Triage routes, it does not solve. Fifteen minutes, three outputs: severity, chain level, owner.
Owners: QA, PO, Tech Lead Phase it lives in: After We Build (Volume V) The corpus principle this enacts: A bug is a witnessed gap between what the chain said would happen and what is happening.
Where it lives in the chain
- After We Build · Bugs and Their Roots — the canon
- After We Build · Severity × Impact — the matrix
- After We Build · Root causes — operational + chain-aware
How to do this
Every bug filed has six dimensions:
- Severity — how bad is it? (Critical / High / Medium / Low)
- Surface — where does the person encounter it? (Page / flow / API / job)
- Class — what kind of break is it? (Functional / performance / data / security / copy / accessibility)
- Chain level — which level of the chain produced it? (Strategy / Discovery / Scope / Execution / Operation)
- Reach — how many people meet it? (One / a segment / everyone)
- Reversibility — can the harm be undone? (Reversible / partial / irreversible)
Priority is auto-calculated from Severity × Impact. Never manual.
What good triage looks like
Daily for the first week post-release, then twice-weekly. Fifteen minutes max. Three outputs only:
- Severity — agreed by the triage attendees, not by the filer alone.
- Chain level — which level should have caught this? Discussed briefly, recorded.
- Owner — a name, not a team. "Esti owns triage of this; she may delegate the fix."
What triage does not do: solve, debate, design fixes. The fix happens after, in normal flow.
The chain level distribution is the diagnostic
The PO reads the chain-level distribution monthly. "Most defects keep tracing to Discovery" is a finding about the team's discovery practice, not about the QA team. "40% scenario-gap" means the amigos template is missing prompts. "25% observation-mismatch" means the briefs are thinner than they need to be.
The bug tracker is not a list of problems. It is a diagnostic instrument for the chain itself.
Related crafts
- Root Cause Analysis (5 Whys) — the deeper read on critical/high bugs
- Support-to-Bug Pipeline — where CS tickets become bugs
- Incident Management — when a bug becomes an incident