# SPEC-D — `agile_iteration` ## Steuerungsmethode — Spec-Tiefe D v0.1 (Kompositions-Methode) **Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen **Stand:** 2026-07-25 **Rolle:** **Kompositions- / Horizont-Methode** (technisch AP2.4: `method_role=modifier`) **Komponiert mit:** `continuous_product`, `sequential_dependency`, `recurring_control` **Nicht:** eigene Vorhaben-Natur / kein Archetyp --- ## D1 Identität — PO ✓ | Feld | Wert | |------|------| | `method_key` | `agile_iteration` | | Fachliche Rolle | **Komposition** (Kernel §6) mit eigener Plan-/Lifecycle-Logik für den Iterations-Horizont | | Technische Rolle | `modifier` (ersetzt Primary nicht; nicht mit `program_delivery`) | | Label (DE) | Agile Iteration / Sprint | | Zweck | Taktet Arbeit in `work_cycle` (Sprint): Planung, Sprint-Backlog, Ausführung, Abschluss/Carryover. Ändert nicht, ob das Vorhaben Projekt (Ende) oder Product (Dauer) ist. | **Klarstellung PO:** „Modifier“ ≠ schwache Logik. Agile hat volle Steuerungslogik für den Sprint — braucht aber eine **Primary** für Vorhaben-Natur (Closure, Gates-Rolle, Dauerbetrieb vs. Ende). --- ## D2 Geltung | Feld | Wert | |------|------| | Komponiert mit | B2b + `continuous_product`; A2 + `sequential_dependency`; A3 + `recurring_control` | | Nicht allein | ohne Primary keine Aussage über Vorhaben-Natur | | Nicht Archetyp | Decision-Lock | --- ## D3 Horizon | Schicht | Owner | |---------|--------| | **Vorhaben- / Plan-Horizont** | Primary (Gate, Orientierung, …) | | **Iterations-Horizont (Ist)** | diese Methode: aktiver `work_cycle` | Beide gleichzeitig gültig; Ist-Default bei aktivem Sprint = Sprint-Backlog. --- ## D4 Leading Work Item **Im Sprint-Slice:** **Action**, gefiltert auf `work_cycle_id` des aktiven Sprints (Primary-Ready ∩ Sprint). **Mit Primary `recurring_control` (A3):** Sprint taktet Actions (Verbesserung/Sonderarbeit). **CadenceInstances** bleiben Leading der Primary und liegen **nicht** als Sprint-Backlog-Todos; Ranking: Cadence overdue/due vor Sprint-Actions (siehe Spec-D `recurring_control` D6). --- ## D5 Lifecycle — eigener Slice (nicht „Flag“) | Sprint-Phase | Steuerung | |--------------|-----------| | Sprint anlegen / geplant | Plan-Container | | Sprint-Planung | Items aus Eingang/Backlog in Sprint legen (Commit/`work_cycle_id`) | | Sprint aktiv | action_selection nur Sprint-Scope; Work-Default Sprint | | Sprint abschließen | Review/Carryover/Unplan; Status `reached`/`closed` | | Reaktivierung | optional laut bestehendem Flow | | Kein aktiver Sprint | Komposition wirkungslos → **nur Primary** (kein leerer Sprint-Sackgasse) | Primary-Lifecycle (intake … closure des Vorhabens) bleibt; dieser Slice **hängt sich** in planning / action_selection / waiting / result_intake / adaptation ein. --- ## D6–D8 Next: ready Actions im aktiven Sprint (Primary-Ready-Regeln ∩ work_cycle). Codes: `sprint_ready`, `sprint_empty`, `sprint_ending`. Attention: leerer aktiver Sprint; Überhang vor Abschluss. Events: activate, complete, carryover, reactivate, unplan. --- ## D9 Nested Kann auf Kind unter B2a liegen, wenn Kind A2/B2b + Agile nutzt. Programm-Meta bleibt `program_delivery`. --- ## D10–D11 OM: `RoadmapItem(work_cycle)` + `actions.work_cycle_id`. Elements: `work_cycle_scope`. `composes_with`: `continuous_product`, `sequential_dependency`, `recurring_control`. --- ## D10b Backlog-Hierarchie & Jira-Abbildung (Agile-Vollmodell) **Verbindlich:** [`ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md`](../ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md) Diese Methode **aktiviert** das Scrum/Jira-Vokabular im Eingang — ersetzt nicht die Primary-Methode. | Jira / Scrum | Kairo (Plan) | Kairo (Ist nach Commit) | |--------------|--------------|---------------------------| | Product Backlog | `BacklogItem` (Eingang) | — | | Epic | `BacklogItem` `item_kind=epic`, Container | Roll-up über Stories/Actions | | Story | `BacklogItem` `item_kind=story`, `parent_backlog_id` → Epic | `Action` `delivery` | | Bug | `BacklogItem` `item_kind=bug` | `Action` `bug` (+ Feature-Ref) | | Issue | `BacklogItem` `item_kind=issue` | `Action` `issue` (+ Feature-Ref) | | Sprint | `RoadmapItem` `work_cycle` | Filter: `Action.work_cycle_id` | | Sprint Backlog | — | committete Actions im Sprint (**keine** BacklogItems) | **Regeln:** - Epic ist **nicht** `RoadmapItem` / Meilenstein. - Epic wird **nicht** direkt convertiert — nur Stories/Bugs/Issues darunter. - Stories können **mehreren Epics** nicht zugeordnet sein (MVP: genau ein `parent_backlog_id`; n:m post-MVP). - Ohne aktiven Sprint: Backlog-Hierarchie bleibt Plan; Leading = Primary Continuous/Sequential. **MVP-Ist:** `story`/`bug`/`issue` ohne Epic/`parent_backlog_id` (AP2.2e). Volllogik = ADP Phase P2–P3. --- ## D10c Dual Commit Path (Primary + Agile) | Pfad | Agile-Profil | Primary Continuous | |------|--------------|-------------------| | A Intake → Commit | Epic/Story → Sprint optional | Idee → Action | | B Direct AP | erlaubt (Spike, Agent) | **Pflicht-Option** Plan → Arbeit | `agile_iteration` verschärft Sprint-Scope; sie **erzwingt** nicht Pfad A für jedes AP. --- ## D12 | Punkt | PO ✓ | |-------|------| | Eigene Steuerungslogik | ja — Planen + Sprint-Lifecycle | | Primary nötig | ja — Vorhaben-Natur | | Bezeichnung | fachlich Kompositions-/Horizont-Methode; technisch modifier | | Ein aktiver Sprint | ja (Decision-Lock) |