Die Ersteller – von der groben Idee zum vollständigen Artefakt

Im Überblick über den Baukasten habe ich beschrieben, warum ich nicht einen Assistenten gebaut habe, sondern die Möglichkeit, sich welche anzulegen. In diesem Beitrag geht es um die erste der vier Operationen: Erstellen.

Das klingt nach der einfachsten. Es ist die, bei der ich am meisten nachgebessert habe.

Die Ausgangslage

Eine Anforderung kommt auf hoher Flughöhe herein:

Nutzer sollen ihre Buchung stornieren können.

Daraus muss ein Artefakt werden, mit dem die nächste Rolle arbeiten kann. Je nach Ebene ist das ein Epic, ein Feature, eine User Story, ein Satz Akzeptanzkriterien, ein Testfall oder ein Lösungskonzept. Jedes hat eine andere Struktur, eine andere Zielgruppe und andere Regeln.

Genau deshalb ist „Erstellen" nicht ein Assistent, sondern eine Familie. Was sie teilen, ist der Ablauf. Was sie unterscheidet, sind Schema und Regeln.

Aufbau eines Erstellungsassistenten

Der letzte Punkt bei den Quellen ist der, den ich zuerst unterschätzt habe. Bestehende, gute Artefakte als Beispiele mitzugeben wirkt stärker als jede Beschreibung im Prompt. Ein Modell, das drei echte User Stories aus dem eigenen Bestand gesehen hat, trifft den Ton besser als eines, dem man den Ton erklärt.

Zum Mitnehmen: die Vorlagen

Die Assistenten arbeiten durchgehend mit Markdown — Eingabe wie Ausgabe. Das hat einen praktischen Grund: Was herauskommt, ist gleichzeitig für Menschen lesbar und für den nächsten Assistenten als Kontext verwendbar, ohne Zwischenschritt.

Die folgenden Vorlagen sind bewusst allgemein gehalten. Sie folgen dem, was sich als Struktur für Epics und User Stories etabliert hat — unternehmensspezifisch ist daran nichts, und genau deshalb müsste jedes Unternehmen sie anpassen. Nimm sie als Ausgangspunkt und passe Felder, Sprache und Konventionen an das an, was bei euch üblich ist. Genau das ist der Sinn eines Baukastens.

Vorlage: Epic

# Epic: <Titel>

## Ziel
<Was soll erreicht werden — eine fachliche Aussage, kein Lösungsvorschlag.>

## Kontext und Auslöser
<Warum jetzt? Welches Problem, welche Chance, welche Verpflichtung?>

## Erfolgsmerkmale
<Woran erkennen wir, dass dieses Epic sein Ziel erreicht hat?
Beobachtbar formuliert.>

| # | Merkmal | Wie messbar |
|---|---------|-------------|
| 1 |         |             |

## Nicht enthalten
<Was bewusst nicht dazugehört. Ohne diesen Abschnitt wächst der Umfang
in der Zerlegung.>

## Betroffene Bereiche
<Fachbereiche, Systeme, Schnittstellen — soweit bekannt.>

## Untergeordnete Features
| # | Feature | Kurzbeschreibung |
|---|---------|------------------|

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

Der Abschnitt Nicht enthalten ist der, den man am leichtesten weglässt und am häufigsten vermisst. Ohne ihn entscheidet der nächste Schritt selbst, was dazugehört.

Vorlage: User Story

# User Story: <Titel>

**Als** <Rolle>
**möchte ich** <Ziel>,
**damit** <Nutzen>.

## Beschreibung
<Zwei bis vier Sätze fachlicher Kontext. Kein Lösungsentwurf.>

## Akzeptanzkriterien

### AK-1 · <Kurztitel>
- **Gegeben** <Ausgangszustand>
- **Wenn** <Auslöser>
- **Dann** <beobachtbares Ergebnis>

### AK-2 · <Kurztitel>
- **Gegeben** …
- **Wenn** …
- **Dann** …

## Fehlerfälle
| # | Situation | Erwartetes Verhalten |
|---|-----------|----------------------|
| 1 |           |                      |

## Abhängigkeiten
<Andere Stories, Systeme, Vorbedingungen. „Keine" ist eine gültige Antwort.>

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

Die Regeln dazu

Die Vorlage allein reicht nicht — sie beschreibt die Form, nicht die Qualität. Dazu gehört ein zweiter Block, den der Assistent als Regelwerk bekommt:

## Regeln für diesen Assistenten

**Pflicht**
- Jedes Akzeptanzkriterium nennt eine beobachtbare Bedingung, einen
  Auslöser und ein erwartetes Ergebnis.
- Mindestens ein Fehlerfall pro Story.
- Alles, was angenommen werden musste, steht unter „Offene Fragen und
  Annahmen" — nicht im Fließtext.

**Verboten**
- Funktionalität ergänzen, nach der nicht gefragt wurde.
- Nicht prüfbare Formulierungen: performant, benutzerfreundlich,
  intuitiv, schnell, modern, robust.
- Annahmen als Tatsachen formulieren.

**Bei Unklarheit**
- Höchstens sechs Rückfragen stellen, dann auf Antwort warten.
- Nicht raten und weitermachen.

Der Abschnitt Offene Fragen und Annahmen ist der wichtigste in der ganzen Vorlage. Dazu gleich mehr.

Was beim ersten Entwurf nicht funktioniert hat

Problem 1: Schöne Kriterien, die niemand prüfen kann.

Die ersten Ergebnisse sahen ausgezeichnet aus. Sauber formuliert, vollständig wirkend, in der richtigen Struktur. Bis jemand versucht hat, daraus einen Testfall abzuleiten.

❌ Das System soll die Stornierung performant verarbeiten.
❌ Der Nutzer soll den Vorgang intuitiv verstehen.

Beides ist nicht falsch. Beides ist nur nicht prüfbar. Und weil es plausibel klingt, fällt es beim Überfliegen nicht auf — es fällt drei Wochen später auf, wenn jemand fragt, wann dieses Kriterium eigentlich erfüllt ist.

Geholfen hat nicht eine bessere Aufgabenbeschreibung, sondern eine Strukturvorgabe. Given/When/Then zwingt zu einer beobachtbaren Bedingung, einem Auslöser und einem erwarteten Ergebnis. Wo eines davon fehlt, fällt es beim Ausfüllen auf — nicht erst beim Testen.

Dazu eine Negativliste im Schema: Wörter wie performant, intuitiv, benutzerfreundlich sind in Akzeptanzkriterien verboten. Das ist grob, und es funktioniert.

Problem 2: Der Assistent hat mitgedacht.

Das klingt zunächst gut. Aus „Nutzer sollen stornieren können" wurde ein Artefakt mit Stornofristen, Teilstornierung, Rückerstattungslogik und Benachrichtigungsmail. Alles sinnvoll. Nichts davon war gefragt.

Das ist gefährlicher als eine Lücke. Eine Lücke sieht man. Eine erfundene Anforderung sieht aus wie Gründlichkeit — und wandert unbemerkt in die Umsetzung, wo sie Aufwand erzeugt, den niemand beauftragt hat.

Die Regel, die daraus entstanden ist, halte ich für die wichtigste im ganzen System:

Ein Assistent darf Annahmen nicht treffen. Er muss sie ausweisen.

Deshalb der Pflichtabschnitt Offene Fragen und Annahmen — mit der Spalte „Auswirkung, falls sie nicht stimmt". Was der Assistent annehmen musste, steht dort: sichtbar, getrennt vom Rest, und damit als Entscheidung für einen Menschen markiert. Aus einer versteckten Erfindung wird eine offene Frage.

Das ist derselbe Gedanke wie der Human-in-the-Loop-Checkpoint aus meiner Agentic-Coding-Serie: Eine Richtungskorrektur ist kostenlos, solange sie früh passiert. Der Unterschied ist nur, dass dort ein Entwickler prüft und hier ein Fachbereich.

Zerlegen ist ein eigener Assistent

Ein Epic in User Stories zu zerlegen ist keine Variante des Erstellens. Der Ersteller füllt eine leere Struktur; beim Zerlegen ist der Inhalt bereits da und muss verteilt werden, ohne dass etwas verlorengeht. Das ist eine andere Aufgabe mit anderen Quellen und einem anderen Hauptrisiko — und deshalb ein eigener Assistent. Um ihn geht es im nächsten Beitrag.

Grenzen

Ein Erstellungsassistent kennt keine Priorität. Er weiß nicht, was dem Unternehmen dieses Quartal wichtig ist, welcher Kunde wartet und welches Thema politisch gerade nicht geht. Er erzeugt ein vollständiges Artefakt — nicht das richtige.

Und er ist nur so gut wie die Musterbeispiele, die er sieht. Wer schlechte bestehende Artefakte als Referenz mitgibt oder nicht alle relevanten Informationen bereitstellt, bekommt konsistent schlechte neue.

Fazit

Erstellen ist die Operation, die am schnellsten beeindruckt und am längsten nachjustiert werden muss. Zwei Regeln haben den Unterschied gemacht: eine Strukturvorgabe, die nicht prüfbare Formulierungen unmöglich macht — und die Pflicht, Annahmen auszuweisen statt sie zu treffen.

Im nächsten Beitrag geht es um die Operation, die direkt danach kommt: aus einem fertigen Artefakt das nächste machen — vom Epic zu den User Stories.

→ Der Baukasten im Überblick

→ Warum KI-Assistenten im Unternehmen an Kontext scheitern (folgt)