Was vorher fertig sein muss
Ein etabliertes Delivery-Setup mit funktionierender Sprint-Cadence, Definition of Done und einer pflegefähigen Backlog-Praxis besteht.
Ein Outcome mit identifizierten Opportunities ist formuliert, an denen sich Discovery-Experimente orientieren.
Was vor Start vorliegen muss
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.
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).
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).
Laufend, parallel zur Delivery-Cadence
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.
Die eine Frage, die diese Methode beantwortet
Welche Annahme testet Discovery in diesem Sprint, welche validierte Story zieht Delivery, und wie bleibt die Übergabe zwischen beiden Tracks kontinuierlich?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Track-Setup | Initial 1 Tag | 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. | 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. |
2Phase 2: Discovery-Cycle | 1-2 Wochen pro Experiment | Top-Annahme aus Backlog ziehen. Experiment designen (Methode, Sample, Erfolgskriterium). Durchführen (Interview, Prototyp-Test, Fake Door, Analytics-Spike). Synthese, Lernreport, Status-Update. | Discovery-Cycle braucht eigene Cadence, nicht Sprint-Cadence. Manche Experimente dauern 3 Tage, andere 4 Wochen. Sprint-Takt zwingen würde Forschung zerreißen. |
3Phase 3: Übergabe Discovery -> Delivery | 30-60 min pro übergehender Story | Validierte Lösung als Delivery-ready Story formulieren: Akzeptanzkriterien, Mockups, Edge Cases, Mess-Setup. Mit Delivery-Team durchsprechen. In Backlog mit Priorität einreihen. | Wer Stories ohne Akzeptanzkriterien übergibt, schiebt Klärungsarbeit in Delivery und reduziert Delivery-Geschwindigkeit. Ready bedeutet wirklich ready. |
4Phase 4: Delivery-Cycle | Sprint-Cadence (1-4 Wochen) | Delivery wie gewohnt: Sprint Planning, Daily, Review, Retro. Mit Schwerpunkt auf validierten Stories. Telemetrie und Outcome-Metriken aus Discovery-Setup live tracken. | 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. |
5Phase 5: Feedback Delivery -> Discovery | Wöchentliche 30 min Sync | Outcome-Metriken nach Release prüfen. Welche Discovery-Annahmen haben sich in Produktion bestätigt? Welche neuen Annahmen treten auf? Discovery-Backlog updaten. | 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. |
Was am Ende rauskommt
Zwei parallele Boards mit klaren Lane-Definitionen, Discovery-Backlog mit Experiment-Status, Delivery-Backlog mit validierten Stories, Lernreport-Verzeichnis, Definition of Ready für Übergänge, Outcome-Dashboard mit Discovery-Metriken in Produktion.
Discovery-Items als Experimente mit Datum und Lernreport-Link. Delivery wie gewohnt. Pro Quartal Outcome-Review mit Verlinkung Discovery-Backlog auf Delivery-Backlog auf Outcome-Metriken.
Kompakte Arbeitsvorlage für Dual-Track Agile mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# 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.Konkret gefülltes Szenario
## Dual-Track-Status — Discovery-Team (KW 20-21, 18.05.2026)
**Outcome (Q2-2026)**: Activation Rate Erstinstaller in Woche 1 von 22% auf 35%.
**Discovery-Track**:
- Experiment E-23 (Wizard statt linearer Slideshow): 5 moderierte Tests, alle 5 schaffen Schritt 3 ohne Hilfe (vorher 2/5). Lernreport @anna 16.05. Status: Validated, an Delivery übergeben.
- Experiment E-24 (Streak-Anzeige ab Tag 1): Fake-Door-Test in Onboarding, 38% Klick-Rate. Status: Running bis 25.05.
- Experiment E-25 (Inline-Support-Bubble): Wireframe, 8 Tests geplant 26.-30.05.
**Übergaben in Sprint 24**:
- Story #491: Wizard-Layout für Schritt 3 (aus E-23). 8 SP. Mockup verlinkt, AK definiert.
**Delivery-Track Sprint 24**:
- Story #491 (validiert), #492-495 (Wartung).
**Outcome-Status**: Activation Rate Woche 1 = 27% (gemessen 14 Tage Postrelease des A/B-Tests aus Sprint 23). +5 Punkte. Noch 8 Punkte bis Ziel.
**Discovery-Kapazität-Schutz**: PM @lisa 50%, Designer @anna 50%, Engineer @ben 30%. Eingehaltene Stunden Woche 20: 78%.Symptome erkennen, gegensteuern
Delivery-Druck zwingt PM und Designer permanent in Sprint-Arbeit, Discovery-Experimente verzögern sich.
Discovery-Stunden pro Person als Kalenderblock. Scrum Master schützt aktiv. Bei Notfall-Eskalation explizit signalisieren, dass Discovery-Cycle verschoben wird.
Übergaben kommen ohne Akzeptanzkriterien, Delivery muss klären statt bauen.
Definition of Ready strikt: AK, Mockups, Edge Cases, Mess-Setup. Stories ohne DoR bleiben in Discovery, gehen nicht ins Sprint Planning.
Experimente werden gemacht, aber niemand prüft, ob Outcome-Metrik in Produktion wirklich steigt.
Pro validiertes Experiment Outcome-Metrik benennen. Postrelease-Tracking 2-4 Wochen. Wenn Metrik nicht erwartet steigt, Discovery-Annahme zurück in Backlog.
Auf einem Board liegen Discovery- und Delivery-Items ohne Trennung, niemand weiß was Status ist.
Zwei Lanes oder zwei Boards strikt trennen. Übergänge als Movement von Discovery-Lane zu Delivery-Lane sichtbar. Reports getrennt.
Discovery-Experimente werden in Sprint-Slices gezwängt, qualitative Studien werden unterbrochen.
Discovery hat eigene Cadence. Sprint-Synchronisation nur an Übergabepunkten. Experimente dürfen mehrere Sprints überspannen.
Reviews zeigen nur Delivery-Output, Stakeholder erkennen Discovery-Wert nicht und kürzen Kapazität.
Discovery-Outcomes in Reviews sichtbar machen. Lernreports und Hypothesen-Status mitziehen. Schutz der Discovery-Kapazität als Strategie-Investition framen, nicht Luxus.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.