Gerade liegt bei dir in Jira, Linear oder einem Slack-Thread ein Feature-Request, in dem so etwas steht wie „Onboarding verbessern“ oder „KI-Vorschläge hinzufügen“. Das Engineering kann loslegen. Das Design kann etwas mocken. Ein KI-Coding-Agent kann daraus sogar Code generieren. Und die Chancen stehen nicht schlecht, dass das Ergebnis am Ende poliert, schnell und falsch ist.
Dieses Scheitern beginnt meist mit einer schlechten User Story. Nicht, weil das Team das Template vergessen hat, sondern weil die Story nie präzise genug wurde, um die Umsetzung zu steuern. Menschliche Teams retten sich manchmal noch über Meetings, Flurfunk und Bauchgefühl. AI Agents können das nicht. Sie führen aus, was du geschrieben hast, nicht, was du gemeint hast.
Wenn du User Stories schreiben willst, mit denen in einem AI-first-Workflow gute Software entsteht, behandle sie als operative Specs. Sie brauchen weiterhin Zusammenarbeit, aber auch so viel Klarheit, dass ein Coding-Agent, die QA und ein Product Manager zum selben Verständnis davon kommen, was „fertig“ bedeutet.
Inhaltsverzeichnis
- Warum die meisten User Stories im KI-Zeitalter scheitern
- Anatomie einer umsetzungsreifen User Story
- Das Wer mit umsetzbaren Personas definieren
- Mit Jobs-to-be-Done zu einem starken Warum
- Eindeutige Akzeptanzkriterien formulieren
- Die Lücke zwischen Spec und Code schließen
- Deine nächsten Schritte und Antworten auf häufige Fragen
Warum die meisten User Stories im KI-Zeitalter scheitern
Eine schwache Story hat dich früher Meetings gekostet. Heute kostet sie dich schlechte Automatisierung.
Ein Product Manager schreibt: „Als User möchte ich eine smartere Suche, damit ich Dinge schneller finde.“ Die Entwicklung versteht darunter ein neues Ranking. Das Design versteht Filter. Ein AI Agent generiert einen Fuzzy-Search-Endpoint und passt die UI an. Alle haben effizient gearbeitet, und niemand hat dasselbe Problem gelöst.
In KI-lastigen Produkten wird diese Lücke noch größer. Laut einem Forrester AI Dev Report aus Q1 2026 kämpfen 55 % der Teams in frühen Phasen mit Spec-Fehlern durch ungeklärte Annahmen, und Gartner-Daten aus 2026 zeigen, dass klassische Stories in KI-Projekten 40 % häufiger scheitern als in Standardanwendungen, weil sich KI nicht deterministisch verhält, wie in dieser NNGroup-Diskussion zu User Story Mapping zusammengefasst.
Die alte Ausrede zieht nicht mehr
Teams wiederholen gern den alten agilen Satz, eine Story sei nur ein Platzhalter für ein Gespräch. Das war schon immer unvollständig. Gefährlich wird es, sobald AI Agents an der Auslieferung beteiligt sind.
Agents leiten die Absicht nicht so ab wie ein Senior Engineer. Sie wissen nicht, welche Unklarheit harmlos ist und welche zu einem Security-Bug, einem Schema-Mismatch oder einem irreführenden UI-Zustand führt. Steht in der Story „Reports exportieren“, muss der Agent wissen, wer sie exportiert, welche Daten enthalten sind, welche Berechtigungen gelten, welches Dateiformat zählt und wie sich ein Fehlschlag verhalten soll.
Praktische Regel: Wenn zwei fähige Leute aus dem Engineering deine Story auf wesentlich unterschiedliche Weise umsetzen könnten, ist sie noch nicht reif für einen AI Agent.
Deshalb sollten Teams, die moderne AI-Agent-Plattformen evaluieren, weniger auf glänzende Demos achten und mehr darauf, wie die Plattform mit Planung, Rückfragen und den Grenzen der Ausführung umgeht. Der Engpass ist selten die Codegenerierung. Es ist die Qualität der Anforderungen.
Was in der Praxis wirklich schiefgeht
Das Fehlermuster ist meist eines von diesen:
- Die Rolle ist generisch. „Als User“ verschleiert, ob jemand kauft, administriert, reviewt oder zum ersten Mal vorbeischaut.
- Das Ziel ist ein Feature-Label. „Ich möchte KI-Vorschläge“ sagt nichts über die Aufgabe, die besser werden soll.
- Der Nutzen ist vorgeschoben. „Damit die App effizienter ist“ ist kein Nutzen für die User.
- Die Story hat keine testbare Ziellinie. Teams fangen an zu coden, bevor sie sich auf Akzeptanzkriterien geeinigt haben.
- Die Story ignoriert die Realität der Umsetzung. Berechtigungen, Abhängigkeiten, Datenverträge und nicht-funktionale Constraints tauchen zu spät auf.
Gute Teams brauchen nicht mehr Stories. Sie brauchen weniger Stories mit schärferer Absicht.
Anatomie einer umsetzungsreifen User Story
Eine brauchbare Story beginnt weiterhin mit dem bekannten Format:
Als [konkrete Rolle] möchte ich [Ziel], damit [relevantes Ergebnis].
Aber dieser Satz ist nur die Eingangstür. Eine ernsthafte Story braucht Struktur drumherum, sonst bleibt sie Backlog-Theater.
Das Template hilft weiterhin, aber nur als Anfang
Die stärkste Grundlage bleibt die Kombination aus den 3 Cs und INVEST.
Ron Jeffries hat das 3-Cs-Framework 2001 eingeführt: Card, Conversation, Confirmation. Teams, die diesen kollaborativen Ansatz nutzen, berichten von bis zu 50 % schnellerer Auslieferung, weil er Missverständnisse reduziert und alle auf testbare Ergebnisse ausrichtet, so PremierAgiles Zusammenfassung der 3 Cs. In der Praxis heißt das: Das geschriebene Ticket ist kurz, im Gespräch werden Annahmen hinterfragt, und die Akzeptanzkriterien legen fest, wann etwas fertig ist.
INVEST gibt dir einen Qualitätsfilter. Eine Story sollte Independent, Negotiable, Valuable, Estimable, Small und Testable sein, also unabhängig, verhandelbar, wertvoll, schätzbar, klein und testbar. Fällt sie bei zwei oder drei davon durch, arbeite nicht „härter“ an ihr. Schreib sie neu oder teil sie auf.
Viele Teams übersehen eine unbequeme Wahrheit. Stories für KI-Workflows müssen für Menschen verhandelbar bleiben, für die Ausführung aber eindeutig sein. Das ist ein engeres Ziel, als die meisten glauben.
Für Teams, die vor der Umsetzung ein stärkeres Planungsartefakt brauchen, kann eine strukturierte Spec helfen. Dieser Leitfaden zu Product Spec Sheets ist eine nützliche Ergänzung, wenn eine einzeilige Story nicht reicht.
Von vage zu umsetzbar
Hier siehst du den Unterschied zwischen einem Backlog-Item, das Reibung erzeugt, und einem, das sauber ausgeliefert wird.
| Element | Vage Story (vorher) | KI-taugliche Story (nachher) |
|---|---|---|
| Rolle | Als User | Als jemand, der wieder einkauft und mehrere gespeicherte Warenkörbe verwaltet |
| Ziel | möchte ich einen besseren Checkout | möchte ich einen früher gespeicherten Warenkorb über meine Kontoseite wiederherstellen |
| Nutzen | damit der Checkout einfacher ist | damit ich einen Kauf abschließen kann, ohne meine Bestellung neu zusammenzustellen |
| Scope | Unklar | Kontoseite, Liste gespeicherter Warenkörbe, Aktion zum Wiederherstellen |
| Annahmen | Versteckt | Nur Warenkörbe aus derselben Region lassen sich wiederherstellen |
| Bestätigung | Keine | Akzeptanzkriterien legen das Wiederherstellen, ungültige Warenkörbe und Berechtigungsprüfungen fest |
| Größe | Zu groß | Ein Flow für wiederherstellbare Warenkörbe in einem Kanal |
| Kontext für die KI-Ausführung | Fehlt | Nennt betroffene Oberflächen, erwartete Zustände und Fehlerverhalten |
Diese Verwandlung zählt, weil vage Stories stille Annahmen geradezu einladen. AI Agents füllen diese Lücken bereitwillig. Ein Dev-Team unter Deadline-Druck auch.
So sieht ein vollständiges Story-Paket aus
Eine starke Story enthält meist diese Teile:
- Kernsatz der Story. Halte ihn kurz und rollenbasiert.
- Kontextnotizen. Erkläre, wo sie in die User Journey passt.
- Grenzen. Halte fest, was außerhalb des Scopes liegt.
- Akzeptanzkriterien. Nutze explizite Bedingungen.
- Technische Notizen. Nenne Abhängigkeiten, Einschränkungen bei den Daten oder betroffene Systeme.
- Offene Fragen. Liste auf, was vor Beginn der Entwicklung noch entschieden werden muss.
Die besten Stories wirken klein, wenn du sie liest, und vollständig, wenn du sie umsetzt.
Wenn dein Ticket nur den Template-Satz enthält, bist du noch nicht fertig mit Schreiben. Du hast nur den Problembereich benannt.
Das Wer mit umsetzbaren Personas definieren
Die meisten schwachen Stories brechen schon bei den ersten drei Wörtern.
„Als User“ ist verbreitet, weil es schnell, neutral und leicht abzunicken ist. Meist ist es auch nutzlos. Es entfernt genau den Kontext, der die Trade-offs im Produkt bestimmt, und so füllt das Engineering die Lücken mit Raterei.
„Als User“ ist meist ein Warnsignal
Unterschiedliche User wollen nicht nur unterschiedliche Features. Sie bringen unterschiedliche Risikotoleranz, unterschiedlichen Zeitdruck und unterschiedliche Erfolgsbedingungen mit.
Wer im Compliance-Bereich vor einem Audit markierte Datensätze prüfen muss, braucht Tempo, Nachvollziehbarkeit und Sicherheit. Wer zum ersten Mal die Preisseite ansieht, braucht Klarheit und Vertrauen. Werden beide zu „User“, schrumpft die Story zu generischer Software.
Dieses generische Schreiben richtet weiter hinten Schaden an:
- Die Priorisierung wird schwächer. Teams können nicht erkennen, welcher Workflow am wichtigsten ist.
- Akzeptanzkriterien werden oberflächlich. Die Tests decken UI-Verhalten ab, nicht den Erfolg der User.
- KI-Ergebnisse werden breiter und schlampiger. Der Agent hat keine konkrete Rolle, auf die er optimieren kann.
Eine Persona in einer User Story muss kein Marketingprofil sein. Sie muss operativ sein. Rolle, Situation und Motivation reichen.
Rollen schreiben, die Entscheidungen verändern
Eine gute Rolle verändert, was du baust.
Vergleich mal:
- Schwach: Als User möchte ich Dokumente hochladen, damit ich Zeit spare
- Besser: Als jemand, der vor einer Frist die Unterlagen für einen Kreditantrag einreicht, möchte ich mehrere PDF-Dokumente in einem Schritt hochladen, damit ich meinen Antrag abschließen kann, ohne den Vorgang zu wiederholen
- Besser für interne Tools: Als Support-Lead mit Eskalationen auf dem Tisch möchte ich die komplette Kundenhistorie sehen, damit ich Account-Probleme lösen kann, ohne das Engineering nach Logs zu fragen
Diese Versionen beeinflussen Design, Workflow, Berechtigungen und Edge Cases. Die generische nicht.
Nutze eine praktische Rollenformel:
| Rollenformel | Beispiel |
|---|---|
| Hauptrolle + Nutzungsmoment | Wiederkehrende Abo-Kundschaft am Smartphone |
| Hauptrolle + Einschränkung | Neu im Dev-Team, ohne Zugriff auf Produktion |
| Hauptrolle + Verantwortung | Finance-Admin beim Abgleich der Monatsrechnungen |
| Hauptrolle + Dringlichkeit | Ops-Lead während eines Incidents |
Ein einfacher Weg zur richtigen Rolle
Frag beim Schreiben einer Story in dieser Reihenfolge:
- Wer spürt den Schmerz zuerst?
- Wer entscheidet, ob das Ergebnis gut genug ist?
- Wer hat Einschränkungen, die die Umsetzung verändern?
- Wer würde eine generische Lösung ablehnen?
Zeigen alle vier Antworten auf dieselbe Rolle, nimm sie.
Zeigen sie auf verschiedene Rollen, verstecken sich wahrscheinlich mehrere Stories in einer. Teil sie auf. Eine Story für den Upload-Flow der Kundschaft. Eine für das Admin-Review. Eine für das Audit-Logging.
Eine Persona ist umsetzbar, wenn sie dich zwingt, mindestens eine Design- oder Umsetzungsoption abzulehnen.
Beispiele, die zu besseren Stories führen
Ein paar Rollen-Upgrades, die Specs zuverlässig verbessern:
- Ersetze breite Labels. Tausche „User“ gegen „Team-Admin in der ersten Woche“, „Owner eines Trial-Accounts“ oder „Kommissionierkraft im Lager“.
- Ergänze Kontext, keine Biografie. „Unter Zeitdruck“, „am Smartphone“, „ohne Fachwissen“ oder „mitten in einer Incident-Response“ reicht.
- Benenne interne Rollen genau. „Support-Agent“, „Security-Reviewer“ und „Finance-Approver“ sind gültig, wenn sie das System wirklich nutzen.
Was nicht funktioniert, ist vorgetäuschte Präzision. „Als 34-jährige urbane Fachkraft“ sagt dem Team nichts Nützliches für einen Billing-Workflow. „Als jemand, der im Finance-Team zum Monatsabschluss Freigaben erteilt“ sagt ihm eine Menge.
Mit Jobs-to-be-Done zu einem starken Warum
Die meisten Fehler im Backlog sehen aus wie Feature-Requests, weil Teams direkt in den Lösungsmodus springen.
„KI-Zusammenfassungen hinzufügen.“ „Filter hinzufügen.“ „Export hinzufügen.“ „Benachrichtigungen hinzufügen.“
Das sind keine Stories. Das sind Wetten auf eine Umsetzung.
Features sind ein schwacher Ausgangspunkt
Am stärksten schreibst du User Stories, wenn du sie im Fortschritt verankerst, den eine Person erreichen will. Genau da hilft Jobs-to-be-Done. Es verschiebt das Gespräch von „Was sollen wir bauen?“ zu „Was will diese Person in dieser Situation erledigen?“
Diese Verschiebung ist bei KI-Produkten besonders wichtig. Wenn jemand nach „KI-Vorschlägen“ fragt, geht es vielleicht um Sicherheit, bevor ein Proposal an die Kundschaft rausgeht, um schnellere Triage einer überlasteten Queue oder darum, repetitives Schreiben zu reduzieren. Das sichtbare Feature ist nicht der Job.
Ein einfacher JTBD-Fragenkatalog
Wenn eine Anfrage vage ist, stell Fragen, die den Job darunter freilegen.
- Auslöser-Frage. Was ist gerade passiert, als du das wolltest?
- Hürden-Frage. Was hat den bisherigen Weg frustrierend oder langsam gemacht?
- Fortschritts-Frage. Was wäre spürbar besser, wenn das funktioniert?
- Constraint-Frage. Was darf nicht kaputtgehen, sich nicht ändern oder nicht schwieriger werden?
- Fallback-Frage. Wenn wir das nicht bauen, welchen Workaround würdest du weiter nutzen?
Diese Fragen sind viel besser als „Welche Features willst du?“, weil sie die Kräfte hinter der Anfrage sichtbar machen.
Aus „KI-Zusammenfassungen für Support-Tickets hinzufügen“ könnte zum Beispiel dieser Job werden: Support-Leads müssen lange Ticketverläufe schnell überfliegen, bevor sie entscheiden, ob sie eskalieren, ohne der KI bei ungeklärten Abrechnungsstreitigkeiten zu vertrauen. Dieser Job legt Scope-Grenzen, Anforderungen an die Konfidenz und Hinweise in der UI nahe. Der ursprüngliche Feature-Request nicht.
So übersetzt du eine Job Story in eine User Story
Eine Job Story beginnt oft so:
Wenn [Situation], möchte ich [Motivation], damit ich [erwarteter Fortschritt].
Dann wandelst du sie in eine Standard-User-Story um, die in dein Backlog passt.
Beispiel:
- Job Story: Wenn ich vor einer Übergabe einen langen Kundenthread durchgehe, möchte ich eine knappe Zusammenfassung der letzten Entscheidungen, damit ich antworten kann, ohne den ganzen Verlauf noch einmal zu lesen.
- User Story: Als Support-Agent bei der Vorbereitung einer Übergabe möchte ich eine KI-generierte Zusammenfassung des aktuellen Kundenthreads sehen, damit ich den Fall schnell übergeben kann, ohne die letzten Entscheidungen zu übersehen.
Diese Übersetzung zählt, weil JTBD den Grund schärft und das User-Story-Format ihn planbar macht.
Ein paar Muster funktionieren gut:
| Muster für die Job Story | Übersetzung als User Story |
|---|---|
| Wenn ich unter Zeitdruck stehe, möchte ich wiederholte Arbeit reduzieren, damit ich schneller fertig werde | Als [Rolle] unter Zeitdruck möchte ich [konkrete Abkürzung], damit ich [Aufgabe] erledigen kann, ohne manuelle Schritte zu wiederholen |
| Wenn ich dem aktuellen Prozess nicht vertraue, möchte ich mehr Transparenz, damit ich sicherer entscheiden kann | Als [Rolle] möchte ich [Review-Feature], damit ich [risikosensibles Ergebnis] prüfen kann, bevor ich handle |
| Wenn Informationen verstreut sind, möchte ich einen Ort, an dem ich sie prüfen kann, damit ich sicher weitermachen kann | Als [Rolle] möchte ich [konsolidierte Ansicht], damit ich [Entscheidung oder Workflow] abschließen kann, ohne zwischen Tools zu wechseln |
Der Twist bei KI-Produkten
KI-Produkte bringen oft zusätzliche Unklarheit mit, weil ihre Ausgaben probabilistisch sind. Die User wollen vielleicht nicht nur eine Antwort. Vielleicht wollen sie ein System, das Rückfragen stellt, seine Konfidenz zeigt, nachvollziehbar bleibt oder sauber an einen Menschen übergibt.
Deshalb ist „damit ich Zeit spare“ für KI-Arbeit meist zu schwach. Bessere Ergebnisse klingen so:
- damit ich den Entwurf prüfen kann, bevor er an die Kundschaft geht
- damit ich fehlende Eingaben bemerke, bevor der Workflow läuft
- damit ich verstehe, warum das Modell diese Aktion vorgeschlagen hat
- damit ich nur die Änderungen freigebe, die regulierte Daten betreffen
Wenn dir der „damit“-Teil nicht hilft, zwischen zwei möglichen Umsetzungen zu entscheiden, leistet er nicht genug.
Eine brauchbare Story beschreibt nicht nur ein Feature. Sie erklärt den Job so gut, dass das Team attraktive, aber irrelevante Lösungen verwerfen kann.
Eindeutige Akzeptanzkriterien formulieren
Ab hier hört eine Story auf, ein Wunsch zu sein, und wird ausführbar.
Der Testable-Teil von INVEST zählt, weil unklare Details Planungszeit verschwenden. Gestützt auf Mike Cohns User Stories Applied und zusammengefasst in Adobes Überblick, hält Mountain Goat Software fest, dass zu wenig Detail eine Hauptursache für 40 % der Schätzfehler ist, weil Teams Sprint-Zeit mit Klärungen verbringen. Klare Akzeptanzkriterien machen eine Story von Anfang an testbar und schätzbar, wie Adobes Leitfaden zu User Stories und Beispielen festhält.
Fang mit dem Happy Path an
Schreib zuerst den einfachen Erfolgsfall. Fang nicht mit jeder Ausnahme an. Fang mit dem Kernversprechen der Story an.
Ein einfaches Format, das gut funktioniert, ist Given / When / Then, auf Deutsch Angenommen / Wenn / Dann.
Beispiel-User-Story:
Als jemand, der schon einmal bestellt hat, möchte ich einen gespeicherten Warenkorb wiederherstellen, damit ich einen Kauf abschließen kann, ohne meine Bestellung neu zusammenzustellen.
Akzeptanzkriterien für den Happy Path:
- Angenommen, ich bin in meinem Konto eingeloggt und habe mindestens einen gespeicherten Warenkorb, wenn ich „Warenkorb wiederherstellen“ wähle, dann werden die Artikel dieses Warenkorbs meinem aktiven Warenkorb hinzugefügt
- Angenommen, das Wiederherstellen klappt, wenn die Warenkorbseite lädt, dann sehe ich die wiederhergestellten Artikel und die aktualisierten Summen
- Angenommen, der gespeicherte Warenkorb gehört zu meinem Konto, wenn ich ihn wiederherstelle, dann muss ich nicht jede Position einzeln neu hinzufügen
Das ist keine Überdokumentation. Es ist das Minimum an gemeinsamem Verständnis, das eine verlässliche Umsetzung braucht.
Dann hol die Edge Cases ans Licht
Die meisten Bugs entstehen in Zuständen, die das Team nie aufgeschrieben hat.
Frag bei jeder Story:
- Was, wenn die Person keine Berechtigung hat?
- Was, wenn benötigte Daten fehlen?
- Was, wenn die Aktion nur teilweise gelingt?
- Was, wenn sich das Objekt geändert hat, seit die Person es zuletzt gesehen hat?
- Was, wenn die KI-Ausgabe unvollständig, unsicher oder widersprüchlich ist?
Mit demselben Warenkorb-Beispiel:
- Angenommen, ich versuche, einen Warenkorb mit nicht verfügbaren Artikeln wiederherzustellen, wenn das Wiederherstellen läuft, dann sehe ich, welche Artikel nicht wiederhergestellt werden konnten
- Angenommen, ich bin ausgeloggt, wenn ich einen Warenkorb über einen Link zu einem gespeicherten Warenkorb wiederherstellen will, dann werde ich aufgefordert, mich einzuloggen, bevor die Aktion weiterläuft
- Angenommen, der Warenkorb wurde in einer anderen Vertriebsregion angelegt, wenn ich ihn wiederherstellen will, dann verhindert das System das und erklärt, warum
Viele Teams verstecken diese Details nachträglich in QA-Notizen oder Bug-Tickets. Das ist zu spät. Wenn das Team den Fehlerzustand im Refinement vorhersehen kann, gehört er in die Akzeptanzkriterien.
Schreib Akzeptanzkriterien für die Fehlerfälle, von denen du schon weißt, dass sie eintreten. Lass sie nicht von der QA neu entdecken.
Für Teams, die Ticket-Inhalte sauber strukturieren wollen, hilft ein praktisches Jira-Issue-Template, Story-Text, Annahmen und Bestätigung an einem Ort zu halten.
Nicht-funktionale Anforderungen ergänzen, solange die Story noch klein ist
Genau hier scheitern die meisten „guten“ Stories trotzdem.
Eine funktionale Story mag klar sein, aber das eigentliche Problem in Produktion zeigt sich bei Security, Performance, Observability oder im Umgang mit Daten. Wenn du für AI Agents schreibst, müssen diese Constraints früh sichtbar sein, weil Agents Architekturstandards aus einem vagen Prompt nicht zuverlässig ableiten.
Schreib nicht-funktionale Akzeptanzkriterien im selben expliziten Stil.
Beispiele für Security:
- Angenommen, ich bin nicht eingeloggt, wenn ich den Endpoint zum Wiederherstellen gespeicherter Warenkörbe aufrufe, dann wird der Zugriff verweigert
- Angenommen, ich versuche, den Warenkorb einer anderen Person wiederherzustellen, wenn die Anfrage validiert wird, dann wird die Aktion abgelehnt
Beispiele für Performance:
- Angenommen, ich habe mehrere gespeicherte Warenkörbe, wenn ich die Liste der gespeicherten Warenkörbe öffne, dann bleibt die Seite unter erwarteter Last reaktionsschnell
- Angenommen, ich stelle einen Warenkorb wieder her, wenn die Summen neu berechnet werden, dann kommt das Ergebnis schnell genug für einen flüssigen Checkout
Beispiele für Zuverlässigkeit:
- Angenommen, das Wiederherstellen bricht mittendrin ab, wenn die Person zum Warenkorb zurückkehrt, dann bleibt der Warenkorb konsistent und es tauchen keine doppelten Artikel auf
Beispiele für Observability:
- Angenommen, ein Wiederherstellen schlägt fehl, wenn das System das Ereignis protokolliert, dann ist der Fehlergrund für Support und Debugging verfügbar
Wenn dein Team nach dem Schreiben der Kriterien ein stärkeres Testdesign braucht, ist dieser Leitfaden dazu, wie man Testfälle schreibt, ein sinnvoller nächster Schritt. Entscheidend ist die Reihenfolge: zuerst die User Story, dann die Akzeptanzkriterien, dann die Testfälle. Wer das umdreht, produziert oft fragile Arbeit.
Die Lücke zwischen Spec und Code schließen
Eine User Story ist nicht fertig, wenn das Produktteam sie versteht. Sie ist fertig, wenn das Engineering sie umsetzen kann, ohne die fehlende Hälfte zu erfinden.
Diese fehlende Hälfte ist meist technischer Kontext. Teams behandeln technische Stories immer noch wie Backlog-Items zweiter Klasse, obwohl gerade sie oft bestimmen, ob ein Feature sauber ausgeliefert wird oder zum fragilen Flickwerk wird.
Ein State of Agile Report von 2025 hält fest, dass 62 % der Teams nicht-funktionale Anforderungen zu den größten Herausforderungen im Backlog zählen, aber nur 18 % eigene technische Stories nutzen. Diese Lücke trägt zu 30 % mehr Problemen in Produktion bei Startups bei, so die User-Story-Diskussion von Agile Modeling.
User Stories brauchen technische Gegenstücke
Eine Story aus Sicht der User sagt, welches Ergebnis zählt. Eine technische Story sagt, was im System existieren muss, damit dieses Ergebnis sicher funktioniert.
Zum Beispiel:
- User Story: Als Support-Agent bei der Vorbereitung einer Übergabe möchte ich eine KI-generierte Zusammenfassung des Threads, damit ich den Fall schnell übergeben kann, ohne die letzten Entscheidungen zu übersehen.
- Technische Story: Als Engineering-Team der Support-Plattform müssen wir Metadaten zur Erzeugung der Zusammenfassung und Verweise auf die Quellnachrichten speichern, damit Zusammenfassungen prüfbar und nachvollziehbar sind.
Die technische Story soll die User Story nicht ersetzen. Sie soll sie stützen.
Diese Unterscheidung zählt, weil ein häufiger Fehler darin besteht, systemzentrierte Stories wie „Als System …“ zu schreiben und den Nutzen für die User komplett zu verlieren. Das führt zu unklaren Zielen, die mit 70 % der gescheiterten Projekte in Verbindung stehen, während die Erfolgsquote von 42 % bei Agile 3-mal so hoch ist wie die 14 % bei Wasserfall, laut den Projektmanagement-Statistiken von Flowlu. Halte das Epic aus Sicht der User oben und leite die technischen Stories darunter ab.
Die Story auf die Codebase abbilden, bevor das Coden beginnt
Diesen Schritt übersehen viele, und genau hier brechen KI-Workflows.
Klär vor Beginn der Umsetzung:
- Betroffene Oberflächen. UI, API, Worker, Schema, Berechtigungsschicht, Analytics, Doku
- Abhängigkeiten. Bestehende Services, geteilte Komponenten, Datenmodelle, Feature Flags
- Risikostellen. Authentifizierung, Migrationen, Nebenläufigkeit, Abwärtskompatibilität
- Wahrscheinliche Dateien oder Module. Nicht jede Datei, nur die Ecke des Codes, in der die Umsetzung wahrscheinlich landet
Das bewirkt zwei Dinge. Schätzungen werden realistischer, und AI Agents machen keine breiten, kontextarmen Änderungen quer durchs Repo.
Ein Planungsprozess, der das Repo kennt, ist weit sicherer, als einem Agent zu sagen, er solle gegen die gesamte Codebase „dieses Feature umsetzen“. Wenn dich dieses Planungsmodell interessiert, lohnt sich dieser Artikel über KI-Planung, die die Codebase kennt.
Der praktische Unterschied ist riesig. Ohne Codebase-Mapping erfindet ein Agent vielleicht ein neues Muster, statt ein bestehendes zu erweitern, dupliziert Validierungslogik oder passt die falsche Integrationsgrenze an. Mit Mapping wird die Umsetzung schmaler und wartbarer.
Ein kurzer Walkthrough hilft:
Was ein Story-Paket mit Codebezug enthalten sollte
Für eine AI-first-Ausführung ergänzt du die Story um einen kleinen technischen Anhang:
| Feld | Was hineingehört |
|---|---|
| Betroffene Komponenten | Wahrscheinliche UI-Screens, Endpoints, Jobs oder Services |
| Auswirkung auf Daten | Neue Felder, Modelländerungen, Migrationen oder keine |
| Security-Hinweise | Berechtigungsprüfungen, Auth-Grenzen, Umgang mit sensiblen Daten |
| Auswirkung auf Tests | Bedarf an Unit-, Integrations- und Regressionstests sowie manuellem Review |
| Rollout-Hinweise | Feature Flag, gestaffeltes Release oder sofortiges Release |
| Vermeiden | Bestehende Muster, die nicht dupliziert werden sollen; Module, die nicht ohne Review angefasst werden |
Eine Story, die nicht auf den wahrscheinlichen Bereich der Umsetzung zeigen kann, ist für autonome Ausführung noch zu abstrakt.
Es geht nicht darum, die Lösung in Prosa vorzuprogrammieren. Es geht darum, vermeidbare Unsicherheit zu beseitigen, bevor die Codegenerierung beginnt.
Deine nächsten Schritte und Antworten auf häufige Fragen
Der Wechsel im Mindset ist leicht gesagt und schwer durchzusetzen.
Hör auf, User Stories als leichtgewichtige Erinnerungen zu behandeln. Behandle sie als gemeinsame Ausführungsverträge für Menschen und KI. Stell die User in den Mittelpunkt, aber hör nicht bei Empathie auf. Ergänze so viel Präzision, dass die Story Übergaben, Automatisierung, Tests und die Realität in Produktion übersteht.
Ein praktischer Workflow für deine nächsten fünf Stories
Wenn dein Backlog chaotisch ist, schreib nicht alles neu. Fang mit den nächsten fünf Items an, die wahrscheinlich gebaut werden.
- Ersetze die generische Rolle. Wenn die Story mit „User“ beginnt, schreib die Rolle um, bis sie Designentscheidungen verändert.
- Formuliere das Ziel rund um einen Job neu. Streich lösungszentrierte Sprache, wo es geht.
- Schärfe den Nutzen. Der „damit“-Teil soll echten Fortschritt beschreiben, nicht allgemeine Bequemlichkeit.
- Ergänze Akzeptanzkriterien. Erst der Happy Path, dann Fehlerzustände, dann nicht-funktionale Constraints.
- Hänge technischen Kontext an. Notiere Abhängigkeiten, betroffene Bereiche und Grenzen der Umsetzung.
Dieser Prozess ist langsamer, als Einzeiler ins Backlog zu werfen. Er ist schneller als Nacharbeit.
Häufige Fragen
Wie klein ist klein bei einer User Story?
Klein heißt: Das Team kann sie verstehen, schätzen und abschließen, ohne dass mitten im Sprint versteckte Teilprojekte auftauchen. Enthält eine Story mehrere Ergebnisse für User, mehrere Berechtigungsmodelle oder ein Schema-Redesign, ist sie nicht klein. Teil sie nach Nutzungsschritt, Workflow-Zweig oder Geschäftsregel auf.
Kann in einer technischen Story das System der User sein?
Meist nicht. Ein häufiger Fehler sind systemzentrierte Stories wie „Als System …“, die den Nutzen für die User verfehlen und zu den 70 % gescheiterten Projekten durch unklare Ziele beitragen, während die Erfolgsquote von 42 % bei Agile 3-mal so hoch bleibt wie bei Wasserfall, wenn Teams die User im Mittelpunkt halten, laut ArgonDigitals Diskussion über User Stories und technische Stories. Bei technischer Arbeit knüpfst du die Story wenn möglich an eine echte Rolle, oder du hängst das technische Item unter ein Epic aus Sicht der User, damit die Wertkette sichtbar bleibt.
Was ist der Unterschied zwischen Akzeptanzkriterien und Definition of Done?
Akzeptanzkriterien gelten für eine bestimmte Story. Sie beschreiben, was wahr sein muss, damit genau dieses Feature abgenommen wird. Die Definition of Done gilt für das ganze Team. Sie umfasst allgemeine Standards für „fertig“ wie Code Review, Tests, Changelog-Updates oder Dokumentation. Akzeptanzkriterien beantworten „Haben wir das Richtige gebaut?“ Die Definition of Done beantwortet „Haben wir es ordentlich fertiggestellt?“
Sollte jede Story nicht-funktionale Anforderungen enthalten?
Nicht jede Story braucht einen langen NFR-Abschnitt, aber jede Story sollte auf Security, Performance und Auswirkungen auf den Betrieb geprüft werden. Wenn irgendetwas davon die Umsetzung verändern könnte, schreib es auf. In KI-Workflows zählt das noch mehr, weil versteckte Constraints genau die Stellen sind, an denen Agents teure Fehler machen.
Wie viel Detail ist zu viel?
Zu viel ist es, wenn die Story Umsetzungsentscheidungen vorgibt, die für das Ergebnis keine Rolle spielen. Gutes Detail klärt Verhalten, Grenzen und Constraints. Schlechtes Detail legt das Team auf ein Dropdown, eine Endpoint-Form oder eine Library fest, bevor jemand Alternativen geprüft hat.
Was, wenn die Anforderung noch unscharf ist?
Lass die Story nicht in die Umsetzung. Schreib offene Fragen direkt ins Ticket, kläre sie im Refinement und gib sie erst dann ans Engineering oder an einen AI Agent. Unklarheit wird nicht billiger, wenn das Coden beginnt.
User Stories von Hand zu schreiben ist der manuelle Weg, und Tekk.coach lässt ihn dir offen: Schreib eine Spec auf deinem Board, und dein Coding-Agent baut sie über den Tekk-MCP-Server. Tekks Loops schreiben außerdem Specs für dich, ausgehend von dem, was sich in deinem Code geändert hat. So oder so sind es die Akzeptanzkriterien, die die Spec beim Merge des PR schließen.