User Story am Ende? Requirements für KI-Agenten
Kann eine KI aus einer User Story Software bauen? Ja. Und genau das ist das Problem. Ein Coding Agent füllt jede Lücke, die ein Team im Gespräch schließen würde, mit einer Annahme. Dieser Beitrag zeigt, welche Requirements-Artefakte darüber entscheiden, ob Sie Arbeit an einen Agenten delegieren können und warum die User Story dabei nicht stirbt, sondern ihre Rolle wechselt.
Die User Story war nie die vollständige Anforderung
Eine User Story sollte nie eine Spezifikation sein. Sie war von Anfang an ein Ausgangspunkt für ein Gespräch, nicht dessen Ergebnis.
Das wird an zwei Punkten oft übersehen. Erstens schreibt Scrum User Stories gar nicht vor. Der Scrum Guide kennt genau drei formale Artefakte: Product Backlog, Sprint Backlog und Increment. Die Story ist verbreitete Praxis, aber keine Voraussetzung.
Zweitens war die Story bewusst unvollständig. Die alte Logik aus Card, Conversation, Confirmation sagt es direkt: Die paar Sätze auf der Karte sollten nie sämtliche Informationen tragen, die für die Umsetzung nötig sind. Die Karte war der Auslöser für ein Gespräch, in dem die Details entstehen.
Die eigentliche Anforderung lag also nie im Ticket. Sie lag im gemeinsamen Kontext des Teams. Und genau dieser Punkt entscheidet über alles Weitere.
Menschen schließen Lücken im Gespräch. Agenten füllen sie mit Annahmen.
Eine User Story funktioniert im Team, weil ihre reale Informationsmenge viel größer ist als der Text auf dem Ticket.
Die Entwicklerin kennt das Produkt. Der Product Owner kennt den fachlichen Hintergrund. Architekturentscheidungen sind bekannt, Sonderfälle wurden im Refinement besprochen, im Repository liegen etablierte Patterns. Bei Unklarheit fragt jemand nach. Die Story ist nur der sichtbare Ausschnitt eines viel größeren geteilten Kontexts.
Bei der Delegation an einen Agenten fällt dieser unsichtbare Kontext weg. Der Agent muss explizit wissen, welche Architekturregeln gelten, welche Abhängigkeiten er verändern darf, wie er Fehler behandelt, welche Tests laufen müssen und woran er erkennt, dass eine Aufgabe fertig ist. Was er nicht weiß, ersetzt er durch eine Annahme.
Aktuelle Coding Agents reagieren darauf mit persistenten Anweisungen. GitHub beschreibt Repository-Instructions ausdrücklich als Weg, einem Agenten Projektstruktur, Coding-Standards sowie Build- und Testregeln mitzugeben. Cursor Rules verankern Domänenwissen und Architekturentscheidungen im Repository. Dateien wie AGENTS.md bündeln projektbezogene Instruktionen an einer festen Stelle.
Damit passiert etwas, das im Kern Requirements Engineering ist: Wissen, das früher implizit im Team lag, wird explizit und maschinenlesbar gemacht.
Was nach der User Story kommt: ein Stack statt eines Artefakts
Die Antwort ist kein neues Superformat, das die User Story ersetzt. Es ist ein Stack aus mehreren Repräsentationen desselben Intents, die zusammenarbeiten.
Fünf Ebenen zeichnen sich ab:
- Intent — Warum soll sich etwas ändern, für wen, mit welchem Nutzen? Hier bleiben User Stories, Jobs to be Done und Problem Statements stark.
- Verhaltensvertrag — Was muss das System konkret tun, welche Fälle sind abgedeckt? Hier gewinnen Acceptance Criteria, Beispiele und klar definierte Systemreaktionen.
- Constraints — Welche Grenzen darf die Umsetzung nicht verletzen? Architektur, Datenschutz, Security, Performance, Schnittstellen, Geschäftsregeln.
- Kontext — Was muss ein ausführendes System dauerhaft über Produkt und Codebasis wissen? Instructions, Rules, projektspezifisches Domänenwissen.
- Ausführung und Verifikation — Wie wird aus Intent kontrolliert eine Änderung? Pläne, Tasks, Abhängigkeiten, Tests, Quality Gates.
Spec-Driven-Werkzeuge zeigen dieses Muster bereits. GitHub Spec Kit erzeugt nicht nur eine Spezifikation, sondern adressiert Unklarheiten vor der Planung, leitet daraus einen technischen Plan und eine Taskstruktur ab und prüft die Artefakte gegeneinander auf Konsistenz. Die eigene Dokumentation nennt Checklists sogar eine Art Unit-Test für Requirements.
Kiro liefert das entscheidende Detail: Die User Story verschwindet dort nicht. Eine requirements.md kann weiterhin User Stories enthalten, ergänzt um strukturierte Acceptance Criteria, Designinformationen und ausführbare Tasks.
Die User Story wird nicht ersetzt. Sie wird eingebettet.
Die Gewinner: überprüfbare Grenzen statt guter Formulierungen
Am stärksten profitieren die Artefakte, die Interpretationsspielraum wegnehmen: Acceptance Criteria, Constraints und Tests.
Acceptance Criteria erklärten bisher einem Menschen, wann eine Anforderung erfüllt ist. Bei agentischer Delivery werden sie zum Steuerungsmechanismus für ein autonom arbeitendes System. Noch deutlicher gilt das für Tests und Quality Gates. Sie prüfen nicht mehr nur am Ende, sondern zwischen den Schritten des Agenten, ob der erwartete Zustand erreicht ist.
Damit verschiebt sich die Kernfrage des Requirements Engineering. Sie lautet nicht mehr „Ist die Anforderung gut formuliert?", sondern „Ist der Zielzustand so präzise beschrieben, dass seine Einhaltung überprüfbar ist?".
Der Unterschied wird an einem Satz sichtbar:
„Die Suche soll schnell sein" löst im Team eine Rückfrage aus. Für eine agentische Pipeline ist „95 Prozent der Suchanfragen werden unter Last in unter 500 Millisekunden beantwortet" das eigentliche Requirement.
Der Punkt ist nicht, dass Maschinen Sprache schlecht verstehen. Überprüfbare Grenzen machen Autonomie überhaupt erst beherrschbar.
Sind Prompts und Context Files jetzt Requirements?
Nein, nicht alle. Aber sie gehören zum System, das aus einer Anforderung eine konkrete Änderung macht und das reicht, um sie ernst zu nehmen.
AGENTS.md, Copilot-Instructions oder Cursor Rules enthalten oft Coding-Standards, Build-Befehle und Konventionen. Das sind keine fachlichen Anforderungen, und „Prompts sind die neuen Requirements" wäre zu grob. Funktional beeinflussen diese Dateien aber unmittelbar, welche Lösung ein Agent erzeugt, welche Grenzen er respektiert und wann er seine Arbeit für abgeschlossen hält. Wenn eine Information genau das steuert, gehört sie zum Requirements Execution System.
Diese Verschiebung hat einen Preis, den man ehrlich benennen muss. Fünf verbundene Repräsentationen desselben Intents synchron zu halten ist teurer, nicht billiger, als ein einzelnes Ticket zu pflegen. Das Drift-Problem zwischen Anforderung, Test, Constraint und Code wird größer, nicht kleiner. Wer den Stack einführt, ohne die Konsistenz zwischen den Ebenen aktiv zu sichern, tauscht ein bekanntes Problem gegen ein schwerer sichtbares.
Ein naheliegender Einwand: Vielleicht ziehen Agenten den Kontext bald selbst gut genug aus der Codebasis, und der ganze Explizit-Zwang wäre nur eine Übergangskrücke. Möglich. Nur verschwindet damit die eigentliche Anforderung nicht. Geschäftsregeln, Sicherheitsgrenzen und der Zielzustand stehen nicht im Code, weil das System sie ja erst erzeugen soll. Was ein Agent aus dem Repository lesen kann, ist die bisherige Lösung, nicht die beabsichtigte.
Was das für Ihren Anforderungsprozess bedeutet
Unter Druck gerät nicht die User Story, sondern die Vorstellung, dass ein einziges Artefakt gleichzeitig Kommunikation, Spezifikation und Übergabe leisten kann. Für einen menschlichen Prozess reichte die Story als kompakter Verweis auf implizites Wissen. Für einen Agenten reicht sie nicht, weil das Wissen fehlt, auf das sie verweist.
Die spannendere Frage ist deshalb nicht „Nutzen Teams weiterhin User Stories?". Fast alle werden es tun. Interessant wäre: Welche Artefakte entscheiden tatsächlich darüber, ob ein Team Arbeit an einen Agenten delegieren kann? Eine Erhebung könnte hier zu einem scheinbaren Widerspruch kommen — etwa, dass fast alle Teams weiter User Stories schreiben, aber kaum eines eine Story unverändert an einen Coding Agent übergeben würde. Diese Zahlen sind noch hypothetisch. Genau deshalb wären sie es wert, erhoben zu werden.
Der praktische Schritt beginnt kleiner: Nehmen Sie ein einziges Feature und machen Sie explizit, was Ihr Team bisher im Kopf ergänzt hat — Constraints, Kontext, überprüfbare Kriterien. Genau diese Übersetzung von implizitem Wissen in verbundene, maschinenlesbare Repräsentationen ist die Aufgabe, für die es NanoVerse gibt.
Der erste Schritt ist ein Gespräch, kein Projekt. In 30 Minuten schauen wir an einem Ihrer Use Cases, welche Anforderungen heute schon delegierbar sind und welche nicht.
→ Jetzt kostenlosen Termin buchen.
Q&A - Häufig gestellte Fragen
Können KI-Agenten aus einer User Story Software bauen?
Ja, technisch erzeugt ein Coding Agent aus einer guten User Story Code. Das eigentliche Problem ist nicht das Können, sondern der Interpretationsspielraum: Was die Story offenlässt, füllt der Agent mit Annahmen, während ein Team an derselben Stelle nachfragen würde.
Ersetzen KI-Agenten das Requirements Engineering?
Nein. Sie verschieben es. Wissen, das früher implizit im Team lag, muss jetzt explizit und maschinenlesbar werden — Architekturregeln, Constraints, Erfolgskriterien. Das Formulieren und Verbinden dieser Informationen ist Requirements-Arbeit, nur an einer anderen Stelle als bisher.
Was ist der Unterschied zwischen User Story und Specification für einen Coding Agent?
Die User Story beschreibt den Intent: warum sich etwas ändern soll und für wen. Eine Specification für einen Agenten ergänzt das um Verhaltensvertrag, Constraints, Kontext und überprüfbare Kriterien. Die Story verschwindet nicht, sie wird in diese präzisere Struktur eingebettet.
Braucht man mit KI-Agenten noch Acceptance Criteria?
Mehr denn je. Bei menschlichen Teams erklären Acceptance Criteria, wann eine Anforderung erfüllt ist. Bei agentischer Umsetzung werden sie zum Steuerungsmechanismus: Sie legen den überprüfbaren Zielzustand fest, an dem ein autonom arbeitendes System seine Arbeit misst.
