Meine Session planen

# Session Brief: Dual-Track Agile

## Ziel
Artefakt: Discovery Backlog

## Arbeitsfrage
Welche Annahme testet Discovery in diesem Sprint, welche validierte Story zieht Delivery, und wie bleibt die Übergabe zwischen beiden Tracks kontinuierlich?

## Kontext
Aktueller Outcome oder Product Goal; Opportunity-Liste; Annahmen-Backlog mit Priorität; Delivery-Backlog mit Ready-Status; Cadence (typisch 2-Wochen-Sprint); Discovery-Methoden-Set (Interview, Prototyp, Fake Door).

## Setup
- Format: Methoden-Session
- Dauer: Laufend, parallel zur Delivery-Cadence
- Modus: Workshop oder async
- Teilnehmende: Discovery-Trio (Product Manager, Designer, Engineer) für Discovery-Track; restliches Engineering-Team für Delivery-Track; Scrum Master oder Team Lead als Schutz der Discovery-Kapazität; Stakeholder für Reviews; Researcher (optional).
- Owner: Discovery-Trio (Product Manager, Designer, Engineer) für Discovery-Track
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Discovery Backlog hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Zwei sichtbar getrennte Boards (Discovery-Track und Delivery-Track) oder zwei Lanes auf einem Board; Experiment-Backlog (Hypothesen, Status, Ergebnis); Delivery-Backlog (validierte Stories); Tracking-Tool mit beiden Tracks; Mess-Setup für Discovery-Outcomes.

## Vorbereitung
Board mit zwei Lanes oder zwei Boards. Discovery-Lane mit Spalten (Idea, Experiment Designed, Running, Synthesis, Validated, Rejected). Delivery-Lane wie gewohnt. Cadence-Termine: Discovery-Sync wöchentlich, Übergabe-Touchpoint zu jedem Sprint Planning.

## Agenda
1. Phase 1: Track-Setup (Initial 1 Tag)
   Owner: Facilitator
   Aktion: Discovery-Trio benennen, Kapazität pro Person festlegen (z. B. 30-50% Discovery, Rest Delivery). Boards einrichten. Discovery-Cadence-Termine im Kalender. Definition of Ready für Übergang zu Delivery. Hinweis: Wenn Discovery-Kapazität nicht geschützt wird, frisst Delivery sie auf. Schutz heißt explizit: pro Person fixe Stunden in Discovery, vor Sprint Planning sichtbar. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Discovery Backlog

2. Phase 2: Discovery-Cycle (1-2 Wochen pro Experiment)
   Owner: Facilitator
   Aktion: Top-Annahme aus Backlog ziehen. Experiment designen (Methode, Sample, Erfolgskriterium). Durchführen (Interview, Prototyp-Test, Fake Door, Analytics-Spike). Synthese, Lernreport, Status-Update. Hinweis: Discovery-Cycle braucht eigene Cadence, nicht Sprint-Cadence. Manche Experimente dauern 3 Tage, andere 4 Wochen. Sprint-Takt zwingen würde Forschung zerreißen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Delivery Backlog

3. Phase 3: Übergabe Discovery -> Delivery (30-60 min pro übergehender Story)
   Owner: Facilitator
   Aktion: Validierte Lösung als Delivery-ready Story formulieren: Akzeptanzkriterien, Mockups, Edge Cases, Mess-Setup. Mit Delivery-Team durchsprechen. In Backlog mit Priorität einreihen. Hinweis: Wer Stories ohne Akzeptanzkriterien übergibt, schiebt Klärungsarbeit in Delivery und reduziert Delivery-Geschwindigkeit. Ready bedeutet wirklich ready. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Experiment-Ergebnisse

4. Phase 4: Delivery-Cycle (Sprint-Cadence (1-4 Wochen))
   Owner: Facilitator
   Aktion: Delivery wie gewohnt: Sprint Planning, Daily, Review, Retro. Mit Schwerpunkt auf validierten Stories. Telemetrie und Outcome-Metriken aus Discovery-Setup live tracken. Hinweis: Delivery sollte für mindestens 70% validierte Stories Kapazität haben, Rest für Wartung und ungeplante Arbeit. Wenn mehr als 30% Notfall, beide Tracks gefährdet. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Validierte Stories

5. Phase 5: Feedback Delivery -> Discovery (Wöchentliche 30 min Sync)
   Owner: Owner
   Aktion: Outcome-Metriken nach Release prüfen. Welche Discovery-Annahmen haben sich in Produktion bestätigt? Welche neuen Annahmen treten auf? Discovery-Backlog updaten. Hinweis: Wer Delivery-Outcomes nicht zurück in Discovery führt, läuft im Kreis. Pro Release-Feature mindestens eine Metrik aus Discovery, die in Produktion gemessen wird. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Discovery Backlog

6. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Discovery Backlog

## Abschluss
- Ergebnisartefakt aktualisieren: Discovery Backlog
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Discovery Backlog: Dual-Track Agile

## Arbeitsfrage
Welche Annahme testet Discovery in diesem Sprint, welche validierte Story zieht Delivery, und wie bleibt die Übergabe zwischen beiden Tracks kontinuierlich?

## Kontext
Aktueller Outcome oder Product Goal; Opportunity-Liste; Annahmen-Backlog mit Priorität; Delivery-Backlog mit Ready-Status; Cadence (typisch 2-Wochen-Sprint); Discovery-Methoden-Set (Interview, Prototyp, Fake Door).

## Beteiligte
- Owner: Discovery-Trio (Product Manager, Designer, Engineer) für Discovery-Track
- Teilnehmende: Discovery-Trio (Product Manager, Designer, Engineer) für Discovery-Track; restliches Engineering-Team für Delivery-Track; Scrum Master oder Team Lead als Schutz der Discovery-Kapazität; Stakeholder für Reviews; Researcher (optional).

## Input
Zwei sichtbar getrennte Boards (Discovery-Track und Delivery-Track) oder zwei Lanes auf einem Board; Experiment-Backlog (Hypothesen, Status, Ergebnis); Delivery-Backlog (validierte Stories); Tracking-Tool mit beiden Tracks; Mess-Setup für Discovery-Outcomes.

## Vorlage
# Dual-Track Agile Arbeitsvorlage

## Ziel

Parallel laufende Tracks für Product Discovery und Delivery innerhalb eines Teams.

## Kontext

Wann und wofür nutzen wir diese Methode?

## Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

## Durchführung

Kurze Notizen entlang des Run Sheets.

## Ergebnisartefakte
- Discovery Backlog:
- Delivery Backlog:
- Experiment-Ergebnisse:
- Validierte Stories:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

## Fertigstellungscheck
- Discovery Backlog ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren