User Stories sind in agilen Teams beliebt. Sie sind kurz, gut lesbar und auf den Nutzen für den Anwender fokussiert. Für die Arbeitsplanung können sie sehr nützlich sein.

Wenn das Ziel jedoch spezifikationsgetriebene Entwicklung ist, reichen klassische User Stories nicht aus. Sie treiben Teams zu Plänen und Aufgabenlisten, anstatt stabile, langlebige Spezifikationen zu schaffen. Dies wird in KI-unterstützter Entwicklung zu einem ernsthaften Problem, wo die Spezifikation präzise und maschinenlesbar sein muss.

Das Problem liegt nicht an der Idee der User Stories. Das Problem ist wie und wo sie verwendet werden.

User Stories beschreiben Arbeit, nicht das System

Eine typische User Story sieht so aus:

“Als Anwender möchte ich X, damit Y.”

Dieser Satz drückt Absicht aus, beschreibt aber nicht das Verhalten des Systems. Es gibt keine Regeln, keine Abläufe, keine Randfälle und keine Einschränkungen.

Um sie umsetzbar zu machen, fügen Teams immer zusätzliche Schritte hinzu:

User Story
→ Verfeinerung
→ Plan
→ Aufgaben

An diesem Punkt ist die Story keine Spezifikation mehr. Das eigentliche Wissen liegt in Plänen, Aufgaben, Kommentaren oder Code. Die Story selbst wird zu einem Koordinationsartefakt für Entwickler.

Spezifikationsgetriebene Entwicklung benötigt etwas anderes. Sie braucht Artefakte, die das System beschreiben, nicht die Arbeit, das System zu bauen.

User Stories sind von Natur aus plangetrieben

User Stories eignen sich gut für Sprintplanung. Sie gehen davon aus, dass Arbeit in Aufgaben zerlegt wird, wie z.B.:

  • Endpoint erstellen

  • Datenbank ändern

  • Service implementieren

Diese Aufgaben beschreiben wie etwas gebaut wird. Sie sind kurzlebig und stark an Technologie und Teamstruktur gebunden.

KI benötigt dies nicht. KI benötigt stabile Eingaben:

  • Geschäftsregeln

  • Workflows

  • Domänenkonzepte

  • Einschränkungen

User Stories werden erst nach Planungs- und Aufgaben-Schritten nützlich. Das macht sie ausfuhrungsgetrieben, nicht spezifikationsgetrieben.

User Stories vermischen Absicht und Lösung

Während der Verfeinerung sammeln User Stories oft Akzeptanzkriterien, technische Notizen und Lösungsansätze. Absicht und Umsetzung werden in einem Artefakt vermischt.

Das macht Änderungen teuer. Wenn sich Anforderungen ändern, müssen die Story, ihre Aufgaben und die technischen Notizen neu geschrieben werden.

Spezifikationsgetriebene Entwicklung vermeidet dies durch Trennung der Anliegen:

  • Anforderungen beschreiben Absicht

  • Use Cases beschreiben Verhalten

  • Modelle beschreiben Struktur

User Stories fassen all dies an einem Ort zusammen, was einfach aussieht, aber nicht gut skaliert.

User Stories sind entwicklerzentriert

Trotz ihres Namens dienen User Stories hauptsächlich Entwicklern und der Sprintplanung:

  • Geschäftsstakeholder sehen keine vollständigen Workflows

  • Tester erhalten kein präzises, testbares Verhalten

  • Architekten erhalten keine stabilen Systemgrenzen

Spezifikationsgetriebene Entwicklung benötigt gemeinsame Artefakte, die für alle Rollen funktionieren, einschliesslich KI-Tools. User Stories erreichen dies selten von selbst.

Warum Use Cases besser geeignet sind

Use Cases konzentrieren sich auf Systemverhalten. Sie beschreiben, wie ein Akteur Schritt für Schritt mit dem System interagiert. Abläufe, Alternativen und Ausnahmen werden explizit gemacht.

Use Cases bieten:

  • klar definiertes Verhalten statt vager Absicht

  • vollständige Workflows statt Fragmenten

  • testbare Szenarien

  • natürliche Brücke zu Automatisierung und KI

Am wichtigsten ist, dass Use Cases beschreiben, was das System tut, nicht wie das Team plant, es umzusetzen. Das macht sie zu einer starken Grundlage für spezifikationsgetriebene Entwicklung.

AI Unified Process und der richtige Platz für User Stories

Der AI Unified Process (AIUP) auf https://aiup.dev lehnt User Stories nicht ab. Stattdessen werden sie am richtigen Ort eingesetzt.

Im AIUP leben User Stories im Requirements-Katalog. Dort erfüllen sie einen klaren Zweck:

  • Geschäftsabsicht erfassen

  • Benutzerziele in einfacher Sprache ausdrücken

  • verfolgbare Identifikatoren bereitstellen

Auf dieser Ebene sind User Stories weder Pläne noch Aufgaben. Sie beantworten warum etwas benötigt wird.

Das Verhalten wird dann mit System-Use Cases beschrieben, und die Struktur wird in Entity-Modellen erfasst. Zusammen bilden diese Artefakte die ausführbare Spezifikation von AIUP.

Diese Trennung ist entscheidend. User Stories erfassen Absicht. Use Cases definieren Verhalten. Modelle definieren Struktur. Keines davon benötigt einen Planungs- oder Aufgabenschritt, um nützlich zu sein.

Spezifikationen müssen Änderungen überstehen

Software ändert sich ständig. Anforderungen entwickeln sich weiter, Vorschriften ändern sich und Domänen wachsen.

In einem spezifikationsgetriebenen Ansatz wie AIUP beginnt die Änderung in der Spezifikation. User Stories im Requirements-Katalog können sich ändern, Use Cases werden entsprechend aktualisiert, und alles andere folgt.

Bei klassischen User Stories, die für die Sprintplanung verwendet werden, passiert das Gegenteil. Stories werden als erledigt markiert, Aufgaben ändern sich, Code entwickelt sich weiter, und die ursprüngliche Absicht geht verloren.

Für KI-unterstutzte Entwicklung ist dies fatal. KI benötigt eine verlässliche, lebendige Spezifikation. Diese kann nicht auf abgeschlossenen Sprint-Stories basieren.

Konklusio

User Stories sind nützlich, um Absicht zu erfassen. Sie sind nützlich, um Arbeit zu planen. Aber sie sind nicht ausreichend als Kernartefakt der spezifikationsgetriebenen Entwicklung.

Spezifikationsgetriebene Entwicklung benötigt präzise, stabile und rollenunabhängige Spezifikationen. Sie benötigt Artefakte, die Absicht, Verhalten und Struktur beschreiben, ohne auf Pläne und Aufgaben angewiesen zu sein.

Use Cases sind besser geeignet für Verhalten. User Stories haben weiterhin ihren Wert, aber nur, wenn sie korrekt eingesetzt werden, wie AIUP es im Requirements-Katalog tut.

Wenn Spezifikationen die Quelle der Wahrheit sein sollen, müssen sie das System beschreiben, nicht den Ausführungsplan. Klassische User Stories treiben uns zu Aufgaben und Plänen. Deshalb sind sie nicht gut geeignet im Zentrum der spezifikationsgetriebenen Entwicklung.