Plan delivery
Turn accepted requirements into outcome stories, size safe vertical slices and place them behind explicit delivery gates.
Use this procedure after the module reference is accepted. The work-register reference owns the identifier, table, status and gate contracts used below.
1. Establish the gate
For each WBS epic, state whether its stories can move:
- Ready — required contracts and decisions are accepted;
- Awaits … — name the exact decision, module contract or external fact;
- Partly delivered — name where remaining dependencies or defects are owned;
- Delivered — every intended story has shipped or been withdrawn.
Write planned stories behind an unresolved gate when their outcomes and requirement links are known. The gate exposes the dependency; it does not make the work active.
2. Write outcome stories
- Use an imperative verb phrase: Register equipment, Cancel a reservation, Close a handover.
- Name an actor from the product reference only when it clarifies ownership. Never invent system as a role.
- Cite requirement identifiers. Never paste their Statement, Rationale or Observable fields.
- Keep one verifiable outcome per story and cut vertically through every layer needed to demonstrate it.
- When a tracker expands the row, write acceptance criteria as one-line EARS
rules:
When …, the <module> shall …. Cite the requirement instead of redefining it.
Definition of done is reserved for conditions every story must satisfy. It is
not a heading for one story's acceptance criteria.
3. Size with a tracer bullet
A story is the narrowest end-to-end slice that leaves the repository green and produces one demonstrable outcome.
| Test | Means |
|---|---|
| One verifiable outcome | someone can observe it and decide whether it works |
| One coherent test seam | it is provable without standing up half the product |
| Bounded blast radius | affected modules and contracts can be named |
| Green at the end | the next story inherits no broken repository |
For a wide migration, use expand → migrate → contract. Each safe migration batch is a story while both forms coexist.
4. Check traceability
Every story cites at least one requirement. Every requirement is cited by a story or by a module-wide definition of done.
module reference work register
BKG-001 ←────────────────────── 01.01
BKG-004 ←────────────────────── 02.01
BKG-005 ←────────────────────── 02.02, 02.03
CAT-008 ←────────────────────── 02.03A requirement with no join is not scheduled for delivery, even when it remains normative.
5. Keep the master plan separate
The module register owns its WBS stories and local gates. The master delivery plan owns cross-module sequence, integration gates and demonstrations. Link the module story codes; never copy their rows.