KI-gestützte User Story Erstellung

User Stories sind essenziell für den Erfolg agiler Softwareprojekte. Sie helfen den agilen Teams, Anforderungen aus Anwendersicht klar zu erfassen und die Entwicklung auf den Mehrwert für die Anwender*innen zu fokussieren. Doch das traditionelle Requirements Engineering stößt insbesondere bei divers bereitgestellten Informationen häufig an menschliche Grenzen. 

Mit unserem User Story Creator (USC) haben wir eine Web-Applikation hergestellt, die unsere Kompetenz im Prompt Engineering und im Requirements miteinander verbindet. Das Ergebnis ist eine wertvolle Unterstützung in der Erstellung von User Stories, die in kürzerer Zeit erreicht wird.

User Stories stehen im Zentrum agiler Softwareprojekte. Sie übersetzen abstrakte Geschäftsideen in Anforderungsartefakte, die den Entwicklungsteams, Fachbereichen und Stakeholdern gleichermaßen verständlich sind. Wer jedoch schon einmal versucht hat aus Workshops, E-Mails, Confluence-Seiten und Ticket-Kommentaren eine konsistente Story zu destillieren, weiß, dass dieser Prozess schnell zum Engpass werden kann. Der Aufwand steigt exponentiell, sobald mehrere Teams beteiligt sind, regulatorische Randbedingungen hinzukommen oder spezifisches Fachvokabular Überhand gewinnt. Spätestens hier stellt sich die Frage, ob künstliche Intelligenz helfen kann, Ordnung in das stetig wachsende Informationsrauschen zu bringen.

Um diesen Engpass aufzulösen, haben wir einen PoC entwickelt, den wir „User Story Creator“ nennen. Die Web-Applikation kombiniert Large-Language-Models mit Retrieval Augmented Generation (RAG), sodass sie auf zwei Arten arbeiten kann. Im Freitextmodus genügt eine grobe Idee oder eine kurze Notiz, damit das Sprachmodell die semantischen Zusammenhänge erschließt und daraus eine vollständig strukturierte Story formuliert, inklusive Akzeptanzkriterien und einem Katalog offener Punkte (entsprechend unserem zugrundeliegenden Prompt). Im Dokumentenmodus wird eine Vektordatenbank nach semantischen Übereinstimmungen zu vorhandenen Spezifikationen, Wikis, E-Mails oder Chat-Kanälen durchsucht; anschließend werden die relevanten Passagen extrahiert und an das Modell als Kontext für die Generierung gegeben. Weil das „Retrieven“ der Informationen modular bleibt, müssen wir das LLM nicht trainieren; eine erneute Indizierung reicht, sobald neue Dokumente hinzugefügt werden.

In rigoros strukturierten Projektdokumentationen, in denen Wissen konsistent und versioniert vorliegt, entfaltet der Creator sein volles Potenzial. Die Zeit bis zum ersten brauchbaren Entwurf sinkt drastisch und die Stories folgen einer einheitlichen Syntax, die sich ohne großen Aufwand an eine bestehende Definition of Ready anpassen lässt. Einen entscheidenden Beitrag liefert der RAG-Workflow, weil er Formulierungen auf eine nachvollziehbare Quelle stützt und dadurch Halluzinationen merklich reduziert.

Gleichzeitig mussten wir feststellen, dass die erzielte Qualität unmittelbar mit der Qualität des Inputmaterials verbunden ist. Liegen Dokumente in widersprüchlichen Versionen vor oder fehlen wichtige Randbedingungen, so reproduziert das LLM diese Unschärfen. Das Team spart dann zwar das Schreiben des ersten User Story Entwurfs auf dem leeren Blatt, gewinnt aber keine Zeit im Vergleich zu einem manuellen Prozess, da die Nacharbeitung ebenso lang dauert. In Projekten mit heterogener Dokumentation erwies sich die automatische Generierung daher als nur bedingt effizient, obwohl sie unter idealen Bedingungen sehr gute Ergebnisse liefert. Ein strukturierter Prozess der Dokumentenauswahl und -vorbereitung ist daher entscheidet für gute Ergebnisse.

Aus der zuvor beschriebenen Erfahrung heraus haben wir die Rolle der KI neu bewertet. Heute setzen wir das Modell bzw. spezifische Prompts seltener ein, um Stories vollständig zu erstellen, sondern vorrangig, um existierende Stories und/oder Epics auf ihre Vollständigkeit und Abhängigkeiten hin zu überprüfen. In diesem Validierungsmodus analysiert das System jede User Story nach verfügbaren Konventionen, auf die es im Creator-Betrieb schon zugreift, und weist mit präzisen Rückmeldungen auf Unschärfen hin. Es erkennt möglicherweise fehlende Akzeptanzkriterien, deckt widersprüchliche Begriffe auf, hinterfragt nicht-funktionale Anforderungen oder rückt datenschutzrechtliche Aspekte ins Blickfeld, die in frühen Phasen oft übersehen werden. Die Validierung schließt damit systematisch jene Lücken, die typischerweise erst in einer Sprint Review oder, noch kostspieliger, nach einem Go-Live sichtbar werden. 

Der Schlüssel zu diesen Ergebnissen liegt in der Trennung von Retrieval und Generation. Statt einer pauschalen Aufforderung „Prüfe diese Story“ bekommt das Modell einen angereicherten Kontext aus vergleichbaren Dokumenten, die ein erfahrener Requirements Engineer auch berücksichtigt. Dies erfolgt entweder über das Einfügen von Dokumenten, die alle Informationen zu den Epics und Stories beinhalten, oder auch über Jira als Datenquelle, mit welcher alle Epics, Stories und Subtasks per JQL-Query in den Kontext geladen werden können. Durch den Verweis auf die Quellen des RAGs bleibt die Argumentation vom Modell transparent, jede Beanstandung lässt sich auf einen konkreten Absatz in einer Spezifikation oder Richtlinie zurückführen. Das verschafft Teams die notwendige Sicherheit im Umgang mit regulatorischen Anforderungen und macht die KI-Entscheidungen auditierbar, ohne zusätzliche Trainingsläufe oder proprietäre Anpassungen am Modell. 

Unsere Bilanz lautet: Ein KI-unterstützter User Story Creator kann bei vollständig gepflegten Ausgangsdaten durchaus Zeit sparen und eine gleichbleibend hohe Formulierungsqualität bieten. In den meisten Projekten ist jedoch nicht die Erstellung, sondern die Sicherstellung der Vollständigkeit und Konsistenz der kritische Punkt. Hier entfaltet die KI als Validator ihren größten Nutzen. Sie erweitert das Vier-Augen-Prinzip um einen jederzeit verfügbaren, digitalen Sparrings-Partner, der die Anforderungsartefakte in Sekundenschnelle überprüft und dadurch hilft, Lücken zu schließen und spätere Nacharbeiten in der Entwicklung zu minimieren. 

Wer den nächsten Schritt in Richtung Requirements Engineering 4.0 gehen möchte, sollte daher zuerst in eine robuste Wissensbasis investieren und anschließend prüfen, wie eine KI-gestützte Validierung in bestehende Backlog-Workflows integriert werden kann.