Beiträge

KI-gestütztes Backlog Refinement: mit LLMs bessere User Stories schreiben

Team von Entwicklern versammelt um einen großen Bildschirm, der eine KI-Assistenten-Oberfläche zeigt, die beim Organisieren von User Stories auf einem digitalen Board hilft

Kelly Lewandowski

Zuletzt aktualisiert am 10/04/20267 Min. Lesezeit

Die meisten Teams, die KI im Refinement ausprobieren, lassen sie zuerst User Stories entwerfen. Das ist der falsche Ansatz. Die eigentliche Zeitersparnis entsteht, wenn man KI nutzt, um Lücken in bereits geschriebenen Stories zu finden: fehlende Randfälle, Annahmen, die niemand hinterfragt hat, Akzeptanzkriterien, die vollständig klingen, es aber nicht sind. Das Entwerfen ist der einfache Teil. Das Aufdecken von Schwachstellen ist der eigentliche Mehrwert der KI. So nutzt du sie, ohne dein Backlog in einen Haufen generischer, plausibel klingender Tickets zu verwandeln.

Wo KI im Refinement echten Mehrwert bietet

Nicht jeder Teil des Refinements profitiert gleichermaßen von KI. Hier ist der Nutzen am größten.

1. Akzeptanzkriterien erweitern

Du schreibst die Akzeptanzkriterien für den Happy Path und bittest dann das LLM, Lücken zu finden. Es wird Randfälle aufdecken, die du vergessen hast: leere Zustände, Berechtigungsgrenzen, Nebenläufigkeitsprobleme, Barrierefreiheitsanforderungen, Fehlerbehandlungspfade. Eine Capgemini-Umfrage aus dem Jahr 2024 ergab, dass KI-generierte Akzeptanzkriterien Nacharbeitstickets um etwa 15 % reduzierten. Die Zeitersparnis im Refinement ist schön, aber weniger Überraschungen mitten im Sprint sind der eigentliche Gewinn. Probiere unseren kostenlosen Akzeptanzkriterien-Generator aus, um das in Aktion zu sehen.

2. Risiken und Abhängigkeiten identifizieren

Gib dem LLM dein Datenmodell, deine API-Oberfläche oder Systemarchitektur und bitte es, Risiken für eine bestimmte Story zu kennzeichnen. Es ist überraschend gut darin, teamübergreifende Abhängigkeiten und Datenmigrationsbedarfe zu erkennen, die bei menschlicher Prüfung übersehen werden. Die Qualität des Kontexts bestimmt die Qualität des Outputs. Ein Prompt nur mit dem Story-Text liefert generische Risiken. Ein Prompt mit der Story plus deinem Schema und vorhandenen verwandten Stories liefert konkrete Hinweise, auf die du tatsächlich reagieren kannst.

3. Zu große Stories aufteilen

Wenn eine Story eindeutig zu groß für einen einzelnen Sprint ist, kann KI INVEST-konforme Aufteilungen vorschlagen. Das Muster ist hier entscheidend. Fordere sie auf, „nach Benutzer-Workflow-Schritt aufzuteilen" oder „nach Datenvariante aufzuteilen", anstatt eine allgemeine Aufschlüsselung zu verlangen. Du bekommst so nützlichere Ergebnisse. Mehr über Aufteilungstechniken findest du in unserem Leitfaden zum Herunterbrechen von Epics in sprint-fertige Stories. Und wenn du experimentieren möchtest, kann der Story Splitter das direkt übernehmen.

4. Stories aus Rohdaten entwerfen

KI kann Meeting-Transkripte, Slack-Threads oder Support-Tickets in strukturierte User Stories umwandeln. Das ist nützlich, birgt aber das höchste Risiko des „plausibel, aber falsch"-Problems (dazu weiter unten mehr). Nutze es als Ausgangspunkt, nicht als fertiges Produkt. Illustration von Rohdaten wie Chat-Nachrichten und Support-Tickets, die durch ein KI-Gehirn gefiltert werden und als strukturierte User-Story-Karten herauskommen

Illustration von Rohdaten wie Chat-Nachrichten und Support-Tickets, die durch ein KI-Gehirn gefiltert werden und als strukturierte User-Story-Karten herauskommen

Ein praktischer Workflow für KI-gestütztes Refinement

Stories vor der Sitzung vorbereiten (10 Min.)

Die Product Ownerin oder der Product Owner schreibt Story-Entwürfe mit grundlegenden Akzeptanzkriterien. Nutze den User Story Generator, wenn du von einer groben Feature-Beschreibung ausgehst. Das sollte nicht lange dauern — grob reicht.

KI-Erweiterung für jede Story durchführen

Gib jede Story mit diesem Prompt an ein LLM: „Angesichts dieser User Story und Akzeptanzkriterien: Liste Randfälle, implizite Annahmen und fehlende Szenarien auf. Kennzeichne außerdem mögliche Risiken oder Abhängigkeiten." Füge relevanten Kontext hinzu (Datenmodell, verwandte Stories usw.).

KI-Output gemeinsam im Team prüfen

Geht die von der KI markierten Punkte im Refinement durch. Sortiert das Rauschen aus, behaltet die echten Treffer. Das Gespräch ist das Entscheidende, nicht der KI-Output selbst.

Mit vollständigerem Kontext schätzen

Stories, die eine KI-Erweiterung durchlaufen haben, bringen Komplexität früher ans Licht. Einige Teams berichten, dass Refinement-Sitzungen 20–30 % kürzer ausfallen, weil weniger „Moment, was ist mit …"-Unterbrechungen während der Schätzung auftreten. Nutze Planning Poker, um mit dem vollständigen Bild zu schätzen.

Die Fallstricke, auf die du achten musst

KI-generierte Story-Inhalte haben spezifische Fehlermodi, die nicht immer offensichtlich sind. Plausibel, aber falsch. LLMs produzieren grammatisch einwandfreie Stories, die fehlerhafte Domänenlogik enthalten. Sie „sehen richtig aus" und passieren das Refinement unangefochten, weil niemand etwas hinterfragt, das sich gut liest. Validiere domänenspezifische Details immer mit jemandem, der das System tatsächlich kennt. Falsche Vollständigkeit. Eine KI generiert eine Liste von 12 Akzeptanzkriterien und das Team nimmt an, sie sei erschöpfend. Ist sie nicht. Das Modell kann nicht wissen, was es über dein System nicht weiß. Behandle KI-generierte Akzeptanzkriterien als Ergänzung, nicht als Ersatz für das Teamwissen. Vereinheitlichung. KI-Stories konvergieren zu generischen Mustern. „Als Benutzer möchte ich Ergebnisse filtern, damit ich finden kann, was ich brauche" ist technisch korrekt und völlig nutzlos. Wenn deine KI-generierten Stories auf jedes Produkt passen könnten, brauchen sie mehr Spezifität. Kompetenzverfall. Juniorentwickler hören auf zu lernen, wie man Arbeit zerlegt, wenn die KI es für sie tut. Lass weniger erfahrene Teammitglieder den ersten Entwurf schreiben und nutze dann KI, um ihn zu erweitern. Refinement bleibt ein Lernmoment. Illustration einer Lupe, die eine User-Story-Karte untersucht und unter der Oberfläche verborgene Probleme und Randfälle aufdeckt

Illustration einer Lupe, die eine User-Story-Karte untersucht und unter der Oberfläche verborgene Probleme und Randfälle aufdeckt

Überspringe nicht die menschliche Prüfung

KI-Output sollte niemals ohne Teamdiskussion direkt ins Backlog gelangen. Wenn niemand im Team ihn geprüft hat, gehört er nicht in den Sprint.

Prompting-Tipps, die tatsächlich funktionieren

Generische Prompts liefern generischen Output. Spezifität ist alles:

Statt	Versuche
„Schreibe eine User Story für Suche"	„Schreibe eine User Story für Volltextsuche über Projektnamen und -beschreibungen, für einen Benutzer, der mehr als 50 Projekte verwaltet"
„Generiere Akzeptanzkriterien"	„Generiere Akzeptanzkriterien für Randfälle unter der Annahme eines mandantenfähigen Systems mit rollenbasierter Berechtigung"
„Teile dieses Epic auf"	„Teile dieses Epic nach Benutzer-Workflow-Schritt auf und halte jede Story unabhängig deploybar"
„Was sind die Risiken?"	„Angesichts dieses Datenmodells [Schema einfügen]: Was sind die Migrationsrisiken und dienstübergreifenden Abhängigkeiten?"

Je mehr dein Prompt dein tatsächliches Produkt widerspiegelt, desto nützlicher ist der Output. Füge dein Schema ein. Verweise auf vorhandene Stories. Gib echte Einschränkungen an.

Wann du KI komplett weglassen solltest

Nicht jede Story braucht die KI-Behandlung. Bugfixes mit klaren Reproduktionsschritten, kleine Textänderungen und einfache CRUD-Operationen sind auf die altbewährte Weise schneller zu verfeinern. Setze KI dort ein, wo der Problemraum mehrdeutig ist, die Systeminteraktionen verworren sind oder dein Team immer wieder mitten im Sprint auf Unbekanntes stößt. Mehr zum Schreiben solider Stories ohne KI findest du in unseren Leitfäden Wie man User Stories schreibt und Wie man Akzeptanzkriterien schreibt.

Jedes leistungsfähige Modell (GPT-4, Claude, Gemini) funktioniert gut. Der Qualitätsunterschied kommt von deinen Prompts und dem Kontext, nicht vom Modell. Gib ihm dein Datenmodell und vorhandene Stories, und selbst ein Mittelklasse-Modell liefert nützlichen Output.

Nein. Nutze KI, um menschlich geschriebene Stories zu erweitern und auf die Probe zu stellen, nicht um sie zu ersetzen. Das Domänenwissen deines Teams macht Stories spezifisch und nützlich. KI hilft dir nur, das zu finden, was du übersehen hast.

Einige Teams berichten von 20–30 % kürzeren Refinement-Sitzungen. Aber der größere Gewinn zeigt sich später: weniger Rückfragen mitten im Sprint und weniger Nacharbeit. Erfasse deine Nacharbeitsrate vor und nach der Einführung, um zu sehen, ob es wirklich hilft.

Indirekt. Besser verfeinerte Stories führen zu schnelleren, genaueren Schätzungen. Einige Teams nutzen KI auch zur Analyse historischer Velocity-Daten. Probiere unseren Schätzkomplexitäts-Analyzer für eine KI-gestützte Komplexitätsbewertung aus.