Skip to content

Epic Naming & Kickoff ​

An Epic is a coherent activity the named person does, not a "big feature." Named after what they do, not after what the system provides. The kickoff produces the shaped artefact that the rest of Volume III hangs from.

Owners: PO, Trio Phase it lives in: What We Build (Volume III) The corpus principle this enacts: The code speaks the brief — and the Epic's name is the first place the chain decides what to speak.

Where it lives in the chain ​

How to do this ​

The Epic name is in the named person's verb form:

  • ✅ "Grade an exam" (what Gal does)
  • ✅ "Reconcile a payment batch" (what Uri does)
  • ❌ "Grading system" (what the system provides)
  • ❌ "Backend reconciliation service" (what the team builds)

The kickoff session — 60–90 minutes, trio plus designer if separate — produces:

  1. Epic name in the form above.
  2. Why this Epic, why now — one sentence linking to the Initiative Brief.
  3. The Epic's prediction — the slice of the Initiative's prediction this Epic moves.
  4. Candidate stories — 5–9 small stories the Epic decomposes into.
  5. Dependencies — what other Epics this depends on or unlocks.
  6. Open questions — what the trio doesn't know yet.

What good practice looks like ​

A team kicks off the "Grade an exam" Epic. The kickoff produces six candidate stories — "open an exam from the dashboard," "score a question," "navigate to the next question," "submit and move to next exam," "undo a graded answer," "flag for second reviewer." The Epic's prediction — "reduce grading session from 47 min to under 15 min for pilot schools" — sits at the top. Each story's purpose can be checked against the prediction.

A team that names Epics as "backend services" and "frontend components" loses the chain at the kickoff. The amigos session has no centre of gravity; the stories drift into infrastructure tickets; the prediction goes unnamed because there's no user to make a prediction about.

200apps · How We Work · NWIRE