epics — technical epics
Technical Epics — when the witness is a system
Some Epics are not user-facing. A database migration. A latency reduction. A replatform from one payment provider to another. The work is real, the value is real, and the temptation is to name them as system tasks: "PostgreSQL 16 migration." "Reduce p99 latency." "Replace Cardcom with Hyp."
These names lose the person. They name a verb in the system's voice rather than someone's voice. And they create the same downstream failure as a feature Epic named after a screen — scope drifts, stories proliferate, nothing constrains the implementation, because no one is named who experiences the change.
The rule holds for technical work too. The person is the operator, the SRE, the admin, the support engineer — whoever experiences the system's behaviour after the change ships. The Technical Design Brief from Volume II is the upstream artifact for these Epics: the witness was the system, observed by the engineer; the Prediction names both a technical metric and a human signal. The Epic carries that human signal forward in its name.
Technical Epic naming
- ✗ "PostgreSQL 16 migration"
- ✗ "Reduce billing pipeline latency"
- ✗ "Replace Cardcom with Hyp integration"
- ✓ "Run a clean billing cycle without manual reconciliation"
- ✓ "Operate a Postgres 16 cluster reliably during peak load"
The technical work is the same. The framing changes what the team will reject. "Replace Cardcom with Hyp" succeeds when Hyp is integrated; "Run a clean billing cycle" succeeds when Uri stops the manual reconciliation. The first is a deliverable. The second is the test the brief was always pointing at.
The Technical Design Brief's Prediction enforces this discipline upstream — it named the human signal at the brief stage. The Epic name is where it survives into JIRA. If you find yourself unable to name a person for a technical Epic, the brief was probably incomplete. Go back to the Decisions and ask whose situation changes.
When a spike has to come first
Sometimes the team cannot yet name the activity because the unknown is too large. Whether a particular technology will work at all. How a third-party API actually behaves under load. What the data looks like in production when migrated. In those cases, a spike sits upstream of the Epic kickoff — a time-boxed investigation that produces an answer rather than a feature. A spike is not an Epic; it is the work that lets the Epic be named honestly. If you've heard of spikes from XP or agile literature, this is the same idea — and the discipline is to keep them small, time-boxed, and outcome-named, so they don't drift into open-ended exploration.