Skip to main content

Keel Board Vocabulary

Keel does not ask you to learn a private language before you can use the board. The right pattern is to start from a familiar job, then map it to the system term that carries the constraint.

Mission​

Everyday language: Objective

A mission is the long-running outcome the board is trying to achieve. It is the top-level frame that gives multiple epics a shared destination.

Use a mission when:

  • the work spans multiple problem areas
  • you need a persistent objective over time
  • you want mission next to tell you what matters strategically

Epic​

Everyday language: Strategic track

An epic is a major problem or opportunity inside a mission. It is where Keel expects a product-level problem statement and rationale, usually in a PRD.md.

Use an epic when:

  • the mission needs to be broken into distinct problem spaces
  • you need to author a clear problem statement before implementation
  • multiple voyages will likely sit under the same strategic thread

Voyage​

Everyday language: Tactical campaign

A voyage is the planned delivery arc for a contained body of work. It is the point where requirements and design are frozen tightly enough for the delivery lane to begin.

Use a voyage when:

  • you are ready to define execution constraints
  • you need SRS.md and SDD.md before stories start
  • the board should know which stories belong to the same planned campaign

Story​

Everyday language: Executable slice

A story is the smallest tracked unit that can be started, submitted, accepted, and evidenced. Stories are where delivery actually happens.

The story is the tracked board object. In public Keel wording, a slice is the operator-facing delivery cut centered on that story plus the context that makes it actionable.

A Keel slice should make four things visible together:

  • board lineage from mission to epic to voyage to story
  • authored artifacts such as the mission charter, epic PRD, voyage SRS, and voyage SDD
  • the implementation boundary the current cut is meant to capture
  • the current board status and the next explicit state change

Use a story when:

  • the slice is small enough to verify in one turn or a few tight turns
  • acceptance criteria can be recorded explicitly
  • you can attach proof before asking for acceptance

Bearing​

Everyday language: Research vector

A bearing is a discovery move used to reduce uncertainty before you lock requirements or design. It is a formal way to say "we need to learn something first."

Use a bearing when:

  • the team needs research before planning work can be trusted
  • architecture or product shape is still foggy
  • you want discovery to be visible instead of hidden inside implementation churn

Routine​

Everyday language: Scheduled contract

A routine is recurring work that pulse can materialize into the board. It keeps maintenance and governance visible without inventing ad hoc tickets.

Use a routine when:

  • work recurs on a schedule
  • the board should generate that work instead of relying on memory
  • maintenance is part of the operating model, not an exception to it

Learn the terms by job, not by memorization​

If you want the operational context behind these terms, read Board Model, Planning And Verification, and Roles And Lanes.