Neulich wollte ich eine neue User Story anlegen. Kleine Sache, dachte ich – eine Funktion, die alte Daten automatisch aufräumt. Ich fange an, die Idee zu tippen, und noch bevor ich den ersten Satz fertig habe, meldet sich meine KI: „Das gibt es schon. Zweimal. Eine davon ist erledigt.“

Ich saß da und wusste kurz nicht, ob ich mich ärgern oder freuen soll. Geärgert, weil ich gerade dabei war, Arbeit zu doppeln, die längst getan war. Gefreut, weil mir das jemand jetzt sagt. Und genau an diesem Punkt hängt das Thema, über das gerade alle streiten: KI-generierte User Stories.

Die will nämlich kaum jemand lesen. Und ehrlich gesagt: ich auch nicht.

Dass es mir jetzt auffällt – an meinem Schreibtisch und nicht erst im Refinement, wo so eine Diskussion die Zeit des ganzen Teams frisst und die Velocity drückt – ist kein Zufall. Genau das ist mein Job: solche Dinge früh erkennen und im Zweifel vorab mit mir selbst und meinen Agenten klären.

Erst der ehrliche Teil: der Schmerz

Die Story von neulich war der harmlose Fall. Da hat es jemand – die KI – rechtzeitig gemerkt. Meistens merkt es keiner. Und dann passiert genau das, was Anforderungsarbeit seit Jahren zäh macht:

Du legst eine Story an, die es längst gibt – nur unter anderem Titel, im falschen Epic, von jemand anderem geschrieben. Du findest sie nicht, weil du gar nicht weißt, dass du suchen müsstest. Zwei Teams bauen dieselbe Sache.

Oder jemand bringt eine Idee auf, die vor zwei Jahren schon einmal auf dem Tisch lag und bewusst verworfen wurde. Die Story liegt irgendwo in Jira – mit Glück archiviert, im schlimmsten Fall längst gelöscht. Mit genug Recherche fände man sie wieder. Aber genau das ist der Punkt: Als PO will ich das Backlog nach vorne bringen, nicht vor jeder Idee zum Detektiv werden und ständig hinterfragen, ob es das nicht schon gab. Diese Sucharbeit brauche ich – und genau die kann mir eine KI abnehmen.

Oder die Story ist sauber formuliert, klingt rund – und im Sprint fällt auf, dass sie am Datenschutz vorbeigeht, ein Sicherheitsloch aufreißt oder einer Architekturentscheidung widerspricht. Jetzt ist es teuer.

Und selbst wenn alles gut läuft: Kaum hast du das Ticket ans Team übergeben, entwickelt es sich in Jira weiter – neu geschnitten, ergänzt, umpriorisiert. Deine Planung steht derweil auf altem Stand. Du merkst es nicht. Bis es kracht.

Das ist der Schmerz. Nichts davon ist spektakulär. Aber es summiert sich – zu doppelter Arbeit, vergessenen Entscheidungen und Stories, die im luftleeren Raum entstehen.

„Keine KI-generierten User Stories“ – und sie haben recht

Wenn ich davon erzähle, kommt oft der Reflex: „Dann lass doch die KI die Stories schreiben.“ Und genauso oft kommt von guten Entwicklern der Gegenreflex: „Bitte nicht. KI-generierte User Stories merke ich sofort – und dann lese ich sie nicht gern.“

Der Frust dahinter ist berechtigt. Nichts ist ermüdender als glatter Text, der so tut, als hätte jemand nachgedacht, aber niemand hat. Gleichzeitig erwarten dieselben Leute, dass ein Product Owner 2026 KI nutzt. Kein Werkzeug in der Hand zu haben, das alle anderen längst haben, wirkt eben auch nicht souverän.

Das klingt nach Widerspruch. Ist es aber nicht. Beide Seiten reden nur über zwei verschiedene Dinge. Das Problem ist nicht, dass KI im Spiel ist. Das Problem ist, was sie tut.

Warum Prüfen das Schreiben schlägt

Eine Story zu schreiben heißt: eine Absicht zu formulieren. Warum bauen wir das? Für wen? Was lassen wir bewusst weg? Das hängt an Kontext, an Historie, an Verantwortung – an Dingen, die in meinem Kopf und in den Köpfen meiner Kollegen stecken, nicht im Trainingsdatensatz eines Modells. Wenn ich das an eine KI abgebe, kommt genau der Text heraus, den keiner lesen will: plausibel und hohl.

Eine Story zu prüfen ist das genaue Gegenteil.

Prüfen heißt: alles gegen alles abgleichen. Gibt es das schon? Widerspricht es einer Entscheidung von damals? Was sagt der Datenschutz, was der Sicherheitsblick, was der Nutzer? Das ist stumpfe, vollständige, ausdauernde Arbeit – und genau da bin ich als Mensch schwach. Ich vergesse Tickets. Ich habe nicht alle Architekturentscheidungen im Kopf. Ich kann nicht gleichzeitig die Security-, die Datenschutz- und die Nutzerbrille tragen.

Eine Maschine kann das. Unermüdlich, bei jedem einzelnen Ticket.

Deshalb schreibt bei mir die KI nicht – sie prüft. Ich behalte den Teil, den nur ich kann: entscheiden, was wir bauen und warum. Sie übernimmt den Teil, den ich alleine nie so gründlich hinbekäme. Das ist keine Bequemlichkeit. Das ist Arbeitsteilung nach Stärken.

Die These, auf der alles aufbaut

Der Mensch besitzt die Absicht. Die Agenten besitzen die Prüfung.

Was am Ende im Ticket steht, wurde nicht geschrieben. Es wurde geprüft – und von mir entschieden. Deshalb sind meine Stories besser durchdacht, seit KI im Spiel ist, nicht schlechter.

Zwei Bausteine davon habe ich hier schon beschrieben: den Interview-Ansatz statt Fragebogen und das Dompteur-Modell mit Guidelines-First. In dieser Serie setze ich sie zu einem kompletten Vorgehen zusammen.

KI ist eine Ergänzung – kein Allheilmittel

Damit das nicht falsch ankommt: Die KI ist bei mir nicht der Chef. Wir Product Owner sind die Profis, die entscheiden – die KI unterstützt. Und Unterstützung heißt für mich ausdrücklich, dass ich auch dann arbeiten kann, wenn sie mal nicht da ist.

Deshalb liegt meine gesamte Wissensbasis – alle Guidelines, alle Stories, alle Entscheidungen – als einfache Markdown-Dateien in Obsidian. Klartext, den jeder Mensch lesen und selbst bearbeiten kann, ohne Spezialwerkzeug, versioniert in Git. Die KI liest genau dieselben Dateien wie ich, kein verstecktes Format dazwischen.

Der Workflow ist KI-basiert, aber nicht KI-abhängig. Ist das Modell mal nicht erreichbar, bin ich offline oder fällt der Dienst aus, verliere ich Tempo – nicht meine Daten und nicht die Kontrolle. Dann mache ich eben von Hand weiter. Genau das ist der Unterschied zwischen einem Werkzeug, das dich stärker macht, und einem, von dem du abhängig wirst.

Was ich dabei gelernt habe

Der wichtigste Perspektivwechsel war, die KI nicht als schnelleren Texter zu sehen, sondern als etwas, das ich alleine nie leisten könnte: Hunderte Tickets vor jeder neuen Idee durchsehen, jede alte Entscheidung parat haben, gleichzeitig aus fünf Blickwinkeln auf dieselbe Anforderung schauen.

Das nimmt mir die Fleißarbeit ab – und lässt mir den Kopf frei für das, was wirklich meine Aufgabe ist.

KI-generierte User Stories im eigentlichen Sinn entstehen bei mir also nicht. Was am Ende rausgeht, ist geprüft – und von mir verantwortet.

Und die Story von neulich? Die habe ich nicht angelegt. Die gab es ja schon.

Das ist der erste Teil einer Serie über mein Vorgehen im Requirements Engineering mit KI-Agenten. Im nächsten Teil geht es ums Fundament: warum eine KI ohne Wissensbasis am Jenga-Turm baut – und was sich ändert, sobald sie kuratierten Kontext bekommt.

Alle Teile der Serie: Zur Themenseite „Requirements Engineering Pipeline“