Eine Story, zwei Phasen — warum Discovery und Delivery zusammengehören

Dual Track Scrum mit separaten Stories ist der sichere Weg in die Unübersichtlichkeit.

Dual Track bedeutet: Discovery und Delivery laufen parallel. Im Discovery reift eine Anforderung zur umsetzbaren Story. Im Delivery wird gebaut und geliefert. Bewährtes Verfahren, kontinuierlicher Fluss.

Was ich dann häufig beobachte: Eine Story wird in getrennte Tickets für Discovery und Delivery aufgeteilt.

Klingt erstmal logisch. Discovery-Ticket in den Sprint ziehen, bearbeiten, abhaken. Dann ein neues Delivery-Ticket anlegen, wieder in den Sprint ziehen. Sauber getrennt.

Das Problem: Es wird getrennt, was zusammengehört.

Ein Beispiel: Eine Story „Als Nutzer möchte ich meine Rechnungen exportieren können.” Im Discovery entstehen Erkenntnisse — Nutzerinterviews, technische Machbarkeit, Designentwürfe. Wenn das Discovery-Ticket geschlossen wird und ein neues Delivery-Ticket entsteht, passiert Folgendes:

• Kontext geht verloren oder wird manuell kopiert.
• Zwei Tickets müssen gepflegt, verlinkt und nachverfolgt werden.
• Stakeholder sehen nicht mehr auf einen Blick, wo eine Story steht.
• Getrennte Schätzungen machen es richtig unübersichtlich.

Multiplizier das mit 30 Stories und du hast ein Board, das niemand mehr überblickt.

Meine These: Discovery und Delivery gehören in eine Story.

Eine Story ist keine einfache Aufgabe. Ich verstehe sie als etwas, das sich über einen längeren Zeitraum entwickelt. Eine Story durchläuft bei mir zwei Phasen — aber sie bleibt eine Story:

Discovery: Idea → Draft → Ready
Delivery: Todo → Doing → Done

Sie taucht damit in unterschiedlichen Iterationen auf: einmal im Discovery-Track, einmal im Delivery-Track. Und wird erst wirklich geschlossen, wenn geliefert wird. Erst dann zähle ich auch die Punkte für die Velocity. Das halte ich für ehrlich und nachvollziehbar.

Auf diese Weise sammelt sich alles Wissen in einer Story. Das erhöht die Übersicht und vereinfacht die tägliche Arbeit.