Der Transformer – vom Epic zu den User Stories

Im vorherigen Beitrag ging es um Assistenten, die aus einer groben Idee ein vollständiges Artefakt machen. Dieser handelt von der Operation, die direkt danach kommt — und die ich zuerst für eine Variante davon gehalten habe: Transformieren.

Das Artefakt ist schon da. Es muss in den nächsten Typ überführt werden.

Die Ausgangslage

Ein Epic liegt vor. Freigegeben, abgestimmt, auf der richtigen Flughöhe. Was fehlt, sind die User Stories, mit denen ein Team arbeiten kann.

Das ist keine kreative Aufgabe. Es ist eine Überführung: definierter Eingangstyp, definierter Ausgangstyp, dazwischen ein Schnitt, der begründet sein muss. Und es ist derselbe Vorgang, den ein Produktteam jede Woche durchführt:

Damit ist der Transformer — wie der Ersteller — kein Assistent, sondern eine Familie. Ich beschreibe hier den Fall, an dem ich am meisten gelernt habe: Epic zu User Stories.

Was diesen Fall so dankbar macht, ist eine Eigenschaft, die man leicht übersieht: beide Enden sind bereits standardisiert. Ein Epic sieht im selben Team immer gleich aus, eine User Story auch. Was sich von Vorgang zu Vorgang ändert, ist der Inhalt — nicht die Form am Anfang, nicht die Form am Ende, und nicht der Weg dazwischen. Genau diese Konstellation ist die, für die sich ein Assistent lohnt: Struktur, wo etwas wiederkehrt.

Warum das kein Erstellen ist

Ein Epic in User Stories zu zerlegen ist keine Variante des Erstellens. Es ist eine andere Aufgabe mit anderen Quellen — sie braucht Kenntnis der bestehenden Struktur, sonst entstehen Schnitte, die nicht zum System passen. Vor allem aber hat sie ein anderes Hauptrisiko:

Der praktische Punkt: Die Versuchung, einen Assistenten zu bauen, der „alles rund um Anforderungen" macht, ist groß. Sie führt zu demselben Ergebnis wie ein einzelner Prompt, der Analyse, Konzept und Code gleichzeitig erledigen soll — zu allem eine halbe Antwort. Die Zerlegung in Rollen gilt für Assistenten genauso wie für Agenten.

Zwei Schritte statt einem: anreichern, dann transformieren

Die erste Fassung machte es in einem Zug: Epic rein, Stories raus. Das funktioniert — und man sieht dem Ergebnis nicht an, worauf es beruht.

Der Grund liegt in der Natur der Quelle. Ein Epic ist absichtlich unvollständig: Es beschreibt das Ziel, nicht die Wege. Zwischen Epic und Stories liegt Wissen, das nirgends im Epic steht — bestehende Systemgrenzen, benachbarte Stories, definierte Begriffe, frühere Entscheidungen. Wer direkt transformiert, überlässt es dem Modell, dieses Wissen zu ersetzen. Und es ersetzt es zuverlässig durch etwas, das gut klingt.

Deshalb zwei Schritte mit einem sichtbaren Zwischenstand:

Der Zwischenstand ist der eigentliche Trick: Er ist prüfbar, bevor er wirkt.

Schritt 1 — Anreichern. Was fehlt, um überhaupt schneiden zu können? Der Assistent trägt zusammen, was in den angebundenen Quellen dazu steht: verlinkte Vorgänge, bestehende Stories im selben Bereich, Schnittstellenbeschreibungen, Glossar. Das Ergebnis ist kein Fließtext, sondern eine Liste — jede Zeile mit ihrer Fundstelle.

Schritt 2 — Transformieren. Erst auf dieser Grundlage der Schnitt und das Füllen des Zielschemas.

Der Aufwand dafür ist ein zusätzlicher Aufruf. Der Gewinn ist eine Stelle, an der ein Mensch in einer Minute erkennt, ob die Grundlage stimmt — statt fünfzehn Stories zu lesen, um denselben Fehler dreimal wiederzufinden.

Aufbau eines Transformationsassistenten

Zum Mitnehmen: die Vorlage für eine Transformation

Die Vorlage beschreibt bewusst nur den Weg, nicht das Ziel: Wie eine User Story auszusehen hat, steht in der Vorlage aus dem vorherigen Beitrag — hier wird sie eingesetzt, nicht wiederholt. Das ist derselbe Gedanke wie im Baukasten selbst: Der Zieltyp ist an einer Stelle definiert, und jeder Assistent, der ihn erzeugt, benutzt dieselbe Definition.

# Transformation: <Quellartefakt> → <Zielartefakt>

## Quelle
<Titel und Stand des Eingangsartefakts.>

## Angereicherter Kontext
| # | Aussage | Herkunft | Wofür relevant |
|---|---------|----------|----------------|
| 1 |         | <Dokument, Vorgang, Artefakt — nachschlagbar> | |

## Schnitt
<Zwei bis vier Sätze: Wonach wurde geschnitten, und warum so und
nicht anders?>

## Abdeckung
| Abschnitt der Quelle | Zielartefakt | Vollständig übernommen? |
|----------------------|--------------|-------------------------|
| <Ziel>               | <ST-1, ST-3> | ja / teilweise + Grund   |

## Ergebnis
<Die erzeugten Artefakte, jeweils in der Vorlage ihres Typs.>

## Nicht übernommen
| Inhalt der Quelle | Grund |
|-------------------|-------|

## Offene Fragen und Annahmen
| # | Annahme | Auswirkung, falls sie nicht stimmt | Wer entscheidet |
|---|---------|------------------------------------|-----------------|

Und das Regelwerk dazu:

## Regeln für diesen Assistenten

**Pflicht**
- Jede Aussage im angereicherten Kontext nennt ihre Herkunft.
  Ohne benannte Quelle keine Anreicherung.
- Jeder Abschnitt der Quelle steht in der Abdeckungstabelle — auch
  der, der bewusst nicht übernommen wurde.
- Jedes erzeugte Artefakt liefert für sich einen fachlichen Nutzen.
- Der Schnitt wird begründet.

**Verboten**
- Nach technischer Schicht, Komponente, Team oder Sprint schneiden.
- Inhalte der Quelle stillschweigend weglassen.
- Beim Anreichern Anforderungen ergänzen, die in keiner Quelle
  stehen — sie gehören unter „Offene Fragen und Annahmen".
- Ein Ergebnis liefern, ohne den angereicherten Kontext auszugeben.

Die Spalte Herkunft und die Abdeckungstabelle sind die beiden Abschnitte, die ich nicht weglassen würde. Warum, steht jetzt.

Was beim ersten Entwurf nicht funktioniert hat

Problem 1: Der Assistent hat zerhackt, nicht zerlegt.

Die erste Fassung lieferte aus einem Epic zuverlässig sieben bis zehn Stories. Vollständig, sauber formuliert, im richtigen Schema. Nur waren sie entlang des Epic-Textes geschnitten: Wo ein System genannt war, entstand eine Story pro System.

❌ Story: Anpassungen im Buchungsservice
❌ Story: Anpassungen in der Oberfläche
❌ Story: Datenmigration für Stornierungen

Das ist ein Bauplan, kein Backlog. Keine dieser Stories liefert für sich etwas, das jemand benutzen kann — sie müssen alle gemeinsam fertig werden, sonst ist gar nichts fertig. Ein Team, das so schneidet, verliert genau die Eigenschaft, wegen der es überhaupt schneidet: früh etwas Fertiges zu haben.

Geholfen hat keine bessere Aufgabenbeschreibung, sondern eine Verbotsliste im Regelwerk und eine einzige Pflichtfrage pro Story: Was kann jemand nach dieser Story tun, was er vorher nicht konnte? Wo die Antwort „nichts, es fehlt noch X" lautet, ist der Schnitt falsch.

Das Modell hatte sich das übrigens nicht ausgedacht. Es hat übernommen, was es in den mitgegebenen Musterbeispielen gesehen hat — und dort wurde seit Jahren so geschnitten. Das ist die unangenehme Kehrseite guter Musterbeispiele: Sie wirken auch dann, wenn sie schlecht sind.

Problem 2: Anreichern wurde zu Erfinden.

Die Trennung in zwei Schritte hatte ich früh eingebaut. Der Zwischenstand sah gut aus — und genau das war das Problem. Er enthielt Zeilen wie „Stornierungen sind bis 24 Stunden vor Reisebeginn möglich". Nicht falsch. Nur stand das nirgends.

Ob der Assistent das aus einer benachbarten Story übernommen, aus einer Doku-Passage geschlossen oder schlicht für plausibel gehalten hatte, war dem Zwischenstand nicht mehr anzusehen. Zwei Schritte später war daraus ein Akzeptanzkriterium, und das sah aus wie jedes andere.

Ein angereicherter Kontext ohne Herkunft ist keine Anreicherung, sondern eine Behauptung.

Deshalb die Pflichtspalte Herkunft, und zwar so konkret, dass sie nachschlagbar ist. Was keine Quelle hat, darf nicht in den Kontext — es wandert unter „Offene Fragen und Annahmen". Aus einer stillen Ergänzung wird eine Entscheidung für einen Menschen.

Das ist derselbe Gedanke wie Offene Fragen und Annahmen beim Ersteller, nur eine Stufe früher: Der Ersteller weist aus, was er annehmen musste. Der Transformer weist zusätzlich aus, woher er weiß, was er weiß.

Der Nebeneffekt war auch hier der eigentliche Gewinn. Die Abdeckungstabelle sollte nur Vollständigkeit nachweisen — sie hat sich als das schnellste Prüfinstrument des ganzen Assistenten herausgestellt. Eine Zeile ohne Zielartefakt ist ein vergessener Teil des Epics, und den sieht man in einer Tabelle sofort, statt ihn drei Wochen später zu vermissen.

Grenzen

Ein guter Schnitt ist nicht eindeutig. Zwei erfahrene Menschen zerlegen dasselbe Epic unterschiedlich, und beide Schnitte können richtig sein. Der Assistent liefert einen begründeten Vorschlag, kein Optimum — und die Begründung ist der Teil, der zählt. Wer nur die Stories liest und den Abschnitt Schnitt überspringt, prüft das Ergebnis, ohne die Entscheidung dahinter zu sehen.

Er kennt die Reihenfolge nicht. Abhängigkeiten kann er aus dem Material ableiten, Lieferdruck nicht. Was zuerst gebaut wird, ist eine Entscheidung mit Kunden, Terminen und Politik darin — die trifft er nicht.

Die Anreicherung ist nur so gut wie das, was angebunden ist. Ohne Zugriff auf den Bestand bleibt Schritt 1 eine kurze Liste, und der Schnitt entsteht faktisch wieder aus dem Epic allein. Das ist derselbe Befund wie überall in diesem Baukasten — und der Grund, warum Kontext einen eigenen Beitrag bekommt.

Fazit

Von den vier Operationen ist Transformieren die, die am unspektakulärsten klingt und den verlässlichsten Nutzen bringt. Nicht weil sie besonders schwer wäre, sondern weil beide Enden standardisiert sind und die Aufgabe sich wiederholt, solange es das Produkt gibt.

Die Regel, die ich mitnehme: Anreichern und Transformieren sind zwei Schritte. Wer sie zusammenzieht, bekommt keinen schlechteren Schnitt — er bekommt einen, dem man nicht ansieht, worauf er beruht. Und was man nicht ansieht, prüft niemand.

Im nächsten Beitrag geht es um die Gegenrichtung: Prüfen. Und um die Feststellung, dass Prüfen deutlich teurer ist als Erstellen.

→ Der Baukasten im Überblick