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