Im Forschungsprojekt DeepQuali<\/a> haben wir einen Ansatz zur LLM-basierten Bewertung der Qualit\u00e4t von User Stories entwickelt. Dabei dient ein Large Language Model<\/a> (LLM) als Unterst\u00fctzung im Backlog-Refinement, bewertet Stories anhand von Qualit\u00e4tschecklisten wie INVEST und der Definition of Ready eines Teams und liefert strukturiertes Feedback mit Bewertungen, Erl\u00e4uterungen, erkannten Problemen und Verbesserungsvorschl\u00e4gen. In einer ersten Evaluation mit zwei mittelst\u00e4ndischen Softwareunternehmen sch\u00e4tzten Expertinnen und Experten insbesondere die klaren Erl\u00e4uterungen des Ansatzes, weil diese die Qualit\u00e4tsbewertung verst\u00e4ndlicher machten. Dar\u00fcber hinaus bewerteten sie die kompakte Zusammenfassung zur Umsetzungsreife als hilfreich, da sie die Einsch\u00e4tzung des Reifegrads von Stories beschleunigte. Gleichzeitig zeigten sich auch Grenzen, etwa wenn bei einzelnen Bewertungen relevanter Projektkontext fehlte. So kam es mitunter zu Fehlalarmen.<\/p>\n DeepQuali implementiert einen LLM-basierten \u00dcberpr\u00fcfungsprozess f\u00fcr User Stories, der Backlog-Eintr\u00e4ge anhand definierter Qualit\u00e4tsregeln bewertet. Um konsistente Ergebnisse sicherzustellen, werden die Inhalte der Stories vor der \u00dcbergabe an das LLM in ein strukturiertes Format \u00fcberf\u00fchrt, und ein Prompt weist das Modell an, eine strukturierte Antwort zu erzeugen.<\/p>\n Dadurch l\u00e4sst sich die Ausgabe in Refinement-Meetings leichter \u00fcberblicken. Au\u00dferdem k\u00f6nnen Teams mehrere Stories einfacher vergleichen, weil die Ergebnisse nach Regeln gruppiert sind. Da Probleme bereits mit konkreten Kriterien verkn\u00fcpft sind, k\u00f6nnen Teams sie schneller in gezielte Anpassungen \u00fcbersetzen. Zus\u00e4tzlich hilft diese Struktur dabei, Aufgaben an die richtigen Personen zu delegieren.<\/p>\n Die Ausgabe ist so gestaltet, dass sie handlungsorientiert und konsistent ist. Daher enth\u00e4lt sie in der Regel eine Bewertung pro Regel zusammen mit einer kurzen Erl\u00e4uterung. Ebenso listet sie konkrete Probleme auf, die den jeweiligen Regeln zugeordnet sind, und erg\u00e4nzt eine Wichtigkeitsstufe zur Priorisierung, weil nicht jedes Problem die Umsetzung blockiert. Abschlie\u00dfend liefert der Ansatz Verbesserungsvorschl\u00e4ge, sodass Teams direkt von der Diagnose zur Umsetzung \u00fcbergehen k\u00f6nnen.<\/p>\n Zus\u00e4tzlich erstellt DeepQuali eine zusammenfassende Bewertung, die angibt, ob eine Story bereit f\u00fcr die Umsetzung ist. Dadurch erhalten Teams ein schnelles Signal zur Umsetzungsreife, das ihnen hilft zu entscheiden, ob eine Story in die Sprint-Planung aufgenommen werden kann.<\/p>\n Im Evaluationskontext war diese Umsetzungsreife an mehrere praktische Kriterien gekn\u00fcpft, weil Teams sich in der Planung auf klare Ma\u00dfst\u00e4be st\u00fctzen. So mussten Stories beispielsweise klare Akzeptanzkriterien und eine ausreichende Beschreibung enthalten. Dar\u00fcber hinaus mussten sie der Teamvorlage entsprechen und eine Aufwandssch\u00e4tzung enthalten, sodass die Zusammenfassung der Umsetzungsreife mit g\u00e4ngigen agilen Planungspraktiken \u00fcbereinstimmt.<\/p>\n INVEST ist eine weitverbreitete Leitlinie f\u00fcr das Verfassen qualitativ hochwertiger User Stories [1]. Im DeepQuali-Ansatz unterst\u00fctzt diese Checkliste die LLM-basierte \u00dcberpr\u00fcfung von User Stories, wobei jeder Buchstabe f\u00fcr eine eigene Qualit\u00e4tseigenschaft steht.<\/p>\n Eine \u00bbDefinition of Ready\u00ab beschreibt die Mindestbedingungen, die eine User Story erf\u00fcllen muss, bevor sie in einen Sprint aufgenommen wird, weil Teams vermeiden wollen, unvollst\u00e4ndige Stories in die Planung zu ziehen. Viele Teams erweitern diese Checkliste daher \u00fcber das grundlegende Story-Format hinaus.<\/p>\n In der Evaluation wurden etwa Kriterien wie die Qualit\u00e4t der Akzeptanzkriterien, das Vorliegen einer Aufwandssch\u00e4tzung, die Vollst\u00e4ndigkeit der Vorlage, Voraussetzungen und die Beschreibung von Testszenarien herangezogen. Da diese Regeln lokale Entwicklungspraktiken widerspiegeln, kann die LLM-basierte \u00dcberpr\u00fcfung von User Stories Stories nach den eigenen Standards des Teams bewerten.<\/p>\n Qualit\u00e4tssicherung erfordert konsistente Ergebnisse. Deshalb priorisiert DeepQuali Stabilit\u00e4t vor Kreativit\u00e4t. Wenn ein LLM f\u00fcr dieselbe Story unterschiedliche Ergebnisse liefert, verlieren Teams schnell das Vertrauen. Daher reduziert der Ansatz die Zuf\u00e4lligkeit in der Modellkonfiguration und erzwingt eine strukturierte Ausgabe. Dadurch werden wiederholte \u00dcberpr\u00fcfungen vorhersehbar und leichter zu interpretieren.<\/p>\n Ein praxistaugliches Anwendungsmuster besteht darin, die Ergebnisse des LLM eher als Checkliste denn als endg\u00fcltige Entscheidung zu betrachten. Teams k\u00f6nnen etwa vor dem Refinement eine kurze Vorabpr\u00fcfung durchf\u00fchren, um fehlende Akzeptanzkriterien oder unklaren Nutzen fr\u00fchzeitig zu erkennen.<\/p>\n Anschlie\u00dfend k\u00f6nnen Teams vor der Sprint-Planung eine zweite \u00dcberpr\u00fcfung durchf\u00fchren, weil diese best\u00e4tigt, ob eine Story f\u00fcr die Umsetzung bereit ist, und so Sprint-Risiken reduziert. In der Praxis ist es zudem sinnvoll, zwischen zwei Ebenen des Feedbacks zu unterscheiden. Zun\u00e4chst listet das Tool Probleme und Erl\u00e4uterungen auf. Anschlie\u00dfend schl\u00e4gt es m\u00f6gliche Verbesserungen vor, sodass Teams die Kontrolle \u00fcber die endg\u00fcltige Entscheidung behalten.<\/p>\n An der Evaluation waren zwei mittelst\u00e4ndische deutsche Unternehmen mit zwei agil durchgef\u00fchrten Projekten aus unterschiedlichen Bereichen beteiligt. Expertinnen und Experten \u00fcberpr\u00fcften eine kleine Auswahl von User Stories und verglichen ihre eigenen Einsch\u00e4tzungen mit den Bewertungen des LLM.<\/p>\n Da der Prototyp nicht direkt in Entwicklungstools integriert war, interagierten die Expertinnen und Experten im Rahmen gef\u00fchrter Workshops und Umfragen mit dem Ansatz. Daher liefern die Ergebnisse vor allem erste Erkenntnisse zur praktischen Nutzbarkeit.<\/p>\n Die Expertinnen und Experten waren sich bei den detaillierten Kriterienbewertungen nicht immer einig. Die \u00dcbereinstimmung war jedoch beim Kriterium \u00bbSmall\u00ab h\u00f6her, und auch bei der Gesamtbewertung der Umsetzungsreife bestand h\u00e4ufiger Einigkeit. Dadurch erwies sich die Zusammenfassung der Umsetzungsreife in Diskussionen als leichter abstimmbar.<\/p>\n Diese Beobachtung unterstreicht eine wichtige Realit\u00e4t der agilen Entwicklung, weil die Qualit\u00e4t von User Stories subjektiv sein kann. Ein LLM kann die Konsistenz daher unterst\u00fctzen, die Abstimmung im Team jedoch nicht ersetzen.<\/p>\n Die Expertinnen und Experten sch\u00e4tzten insbesondere die Erl\u00e4uterungen des Ansatzes, weil diese nachvollziehbar machten, warum eine Story eine bestimmte Bewertung erhielt. \u00dcberdies halfen sie den Teams bei der Entscheidung, was zuerst verbessert werden sollte.<\/p>\n Auch die Zusammenfassung der Umsetzungsreife erwies sich als n\u00fctzlich, weil sie einen schnellen \u00dcberblick \u00fcber die Qualit\u00e4t der Stories bietet. Dadurch k\u00f6nnen Teams schneller entscheiden, ob eine Story f\u00fcr die Umsetzung bereit ist. Kurze Erl\u00e4uterungen in Kombination mit einem klaren Hinweis auf die Umsetzungsreife k\u00f6nnen daher hilfreicher sein als komplexe Bewertungsschemata.<\/p>\n W\u00e4hrend der Evaluation zeigten sich drei praktische Einschr\u00e4nkungen. Erstens erfordern einige Pr\u00fcfungen Backlog-Kontext, sodass fehlender Kontext die Bewertung von Abh\u00e4ngigkeiten beeintr\u00e4chtigen kann. Zweitens k\u00f6nnen Fehlalarme das Vertrauen mindern, weshalb weniger, aber pr\u00e4zisere Ergebnisse vorzuziehen sind. Drittens variieren die Erwartungen an die Gr\u00f6\u00dfe von Stories zwischen Unternehmen, sodass die Interpretation des Kriteriums \u00bbSmall\u00ab den lokalen Schreibgewohnheiten entsprechen muss.<\/p>\nWie die LLM-basierte \u00dcberpr\u00fcfung von User Stories funktioniert<\/h2>\n
Vom Backlog-Eintrag zum strukturierten Feedback<\/h3>\n
![\"Workflow](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2026\/03\/PROFES-2025-DeepQuali-Evaluation-Artwork.png\")
Ausgabe der LLM-basierten \u00dcberpr\u00fcfung von User Stories<\/h3>\n
Umsetzungsreife von User Stories in der LLM-basierten \u00dcberpr\u00fcfung<\/h3>\n
INVEST-Kriterien in der Qualit\u00e4tspr\u00fcfung von User Stories<\/h3>\n
\n
\nEine Story sollte umsetzbar sein, ohne von noch nicht abgeschlossenen Stories abh\u00e4ngig zu sein. Dadurch werden Abh\u00e4ngigkeiten reduziert und Teams vermeiden Wartezeiten w\u00e4hrend eines Sprints.<\/li>\n
\nEine Story sollte eher das Ziel als eine fest vorgegebene L\u00f6sung beschreiben, damit das Team weiterhin verschiedene Umsetzungsoptionen diskutieren kann.<\/li>\n
\nDie Story sollte einen klaren Mehrwert f\u00fcr Nutzerinnen und Nutzer oder Stakeholder bieten, weil dies die Priorisierung erleichtert und die Entwicklung auf echten Nutzen fokussiert.<\/li>\n
\nDas Team muss in der Lage sein, den Aufwand zu sch\u00e4tzen. Ist das schwierig, fehlt der Story h\u00e4ufig Kontext oder eine klare Abgrenzung des Umfangs.<\/li>\n
\nDie Story sollte in einen Sprint passen. Ist sie zu gro\u00df, sollte sie in kleinere Einheiten aufgeteilt werden, die weiterhin Mehrwert liefern.<\/li>\n
\nDer Erfolg muss \u00fcberpr\u00fcfbar sein. Deshalb sollten Akzeptanzkriterien und Testszenarien klar definiert sein.<\/li>\n<\/ul>\nDefinition of Ready in der Qualit\u00e4tspr\u00fcfung von User Stories<\/h3>\n
Zuverl\u00e4ssigkeit der LLM-basierten Qualit\u00e4tspr\u00fcfung von User Stories<\/h3>\n
Einsatz der LLM-basierten \u00dcberpr\u00fcfung von User Stories im Backlog-Refinement<\/h3>\n
Evaluation des LLM-Ansatzes zur \u00dcberpr\u00fcfung von User Stories<\/h2>\n
Aufbau der Studie<\/h3>\n
\u00dcbereinstimmungbei der Umsetzungsreife gr\u00f6\u00dfer als bei den Detailbewertungen<\/h3>\n
Wo der Ansatz am meisten half<\/h3>\n
Wo es zu Schwierigkeiten kam<\/h3>\n