Für komplexe Domänen mit zahlreichen eng verzahnten Geschäftsobjekten, gesetzlichen Vorgaben und daraus resultierenden Geschäftsprozessen  erwies sich diese Kombination später als eingeschränkt im Vergleich zu den früher eingesetzten Techniken für professionelles Anforderungsmanagement. Auf Grund der großen Popularität und Vorteile "schlanker" Vorgehensweisen, wollte aber kaum jemand zu schwergewichtigen Methoden und Werkzeugen zurückkehren, die Kreativität und den direkten Kontakt mit dem Kunden einschränken.

Die klassische Technik der "User Stories"

User Stories berücksichtigen ausgewählte Erkenntnisse der kognitiven Psychologie: Menschen ordnen ihre Welt in Akteuere, Beziehungen zwischen Objekten und deren Verhalten mit Hilfe von Abstraktion. Menschen können vor diesem Hintergrund Wünsche äußern, begründen und bewerten. Die in der ursprünglichen User Story-Technik vorgeschlagene Struktur vernachlässigt wichtige Aspekte echter Geschichten, weil  zu Beginn der agilen Revolution versucht wurde, Anforderungen auf kurze Überschriften auf Papier-Karten zu reduzieren, und darüber hinaus nur Abnahmekriterien (Rückseite der Karte), den Produkt-Code (Programmiersprache) und die persönliche Abstimmung zuzulassen. Der Beitrag "Agile Missverständisse" erläutert, warum dieser Ansatz in der Praxis nur für sehr einfache und kurzlebige Produkte ausreicht.

Der inhaltliche Umfang von User Stories ist für die Verwendung in einem Management Rahmenwerk konzipiert, und soll vor der Umsetzung so weit ausgearbeitet sein, dass die damit verbundenen Aufgaben vom gesamten Team in ein bis zwei Tagen erledigt werden können. Der inhaltliche Umfang ist folglich nicht zur effizienten Beschreibung strukturierter Anforderungen gedacht.

User Stories werden vom Product Owner zur Bereitstellung eines (meist digitalen) Produktes in persönlicher Abstimmung mit fachlichen AnsprechpartnerInnen (EndbenutzerInnen, Power UserInnen, ExpertInnen) skizziert und dokumentiert. Dazu eigenen sich unterschiedliche Workshop-Techniken und Brainstormings, da wenig formale Vorgaben zu berücksichtigen sind. Erste User Stories werden in einem Vorbereitungs-Sprint gesammelt und dann laufend ergänzt, verfeinert und ggfs. auch wieder verworfen. Der Product Owner kann während laufenden Sprints die Dokumentation von User Stories aus Workshops auch an andere Scrum Rollen delegieren, allerdings ohne die finale Verantwortung für ihre Korrektheit und Vollständigkeit abzugeben.

User Stories werden nach vereinbarten Regeln in der fachlichen Sprache des Kunden verfasst, die neben empfohlenen Satzmustern (Templates) diverse Best Practices aus dem Anforderungsmanagement berücksichtigen können, z.B. die Sicherstellung des einheitliche Gebrauches von Begriffen durch laufend erweiterte Glossare. Davon wird in der Praxis leider selten Gebrauch gemacht.

Typisches Satzmuster (Templates) für User Stories:
Als <Rolle> will ich <Aktion,Funktion> [,so dass <Grund, Ziel>]

Zur Begrenzung der Satzlänge wird dabei häufig auf das Konzept des verwendeten Geschäftsobjektes (Daten- und Schlüssel-Analyse) und des beteiligten IT-Systems (Produkt, Schnittstelle) verzichtet oder vergessen. Diese wichtigen Informationen werden z.B. in der Domänen-Analyse, Anwendungsfall-Analyse, Schnittstellen-Analyse und Prozess-Analyse berücksichtigt. Es fehlt zudem die Möglichkeit, Abläufe oder fachliche Beziehungen zu fordern.

Merkmale guter Stories und Akzeptanzkriterien für Abnahmetests

Das Akronym INVEST hilft beim Merken wichtigsten Merkmaler guter Anforderungen und User Stories - mehr dazu siehe hier.

Es wird zudem empfohlen, schriftlich "Akzeptanzkriterien" für den späteren Abnahmetest zu dokumentieren, jedoch ohne konkrete Testdaten und Testszenarien. Darüber hinaus gehende Details wie Testfälle und Testdaten sollten nur mündlich oder in Informationssystemen mit Verweis auf den zugehörigen Applikations-Code ausgetauscht werden.

Technischer Hinweis: Idealerweise schneidet eine gute User Story vertikal durch alle Schichten der technischen Architektur digitaler Produkte von der Benutzermaske bis zur Speicherung und Infrastruktur, um die eine Subdomäne des Produktes um eine klar abgegrenzte, kleine (vgl. "small") Funktionalität zu erweitern, oder um eine Funktionalität abzuändern. Andere Schnitttechniken konzentrieren sich auf ausgewählte Domänen-Daten, Akzeptanztests oder bestimmten Abhängigkeiten.

User Stories können fachliche funktionale und nicht funktionale Anforderungen darstellen, wenn dafür eine entsprechendes Satzmuster (Template) bereit gestellt wird. User Stories eignen sich weniger für technische Anforderungen, da für diese kein unmittelbarer Geschäftswert, und oft auch keine "Umsetzung" in einem messbaren Schritt festgemacht werden kann.

Neben User Stories wurden in der älteren Literatur auch Epics, gelegentlich auch Spikes, Themes und ein technisches Backlog zur Ergänzung vorgeschlagen. Epics werden als formlose Platzhalter für noch nicht zu Stories ausgearbeitete Erinnerungen für Funktionalität verstanden.  Erweiterte "User Stories" und andere Techniken für das agile Anforderungs-Management ergänzen bei Bedarf den klassischen Ansatz von User Stories z.B. für die Anwendung in komplexen und langlebigen fachlichen Anwendungsbereichen wie dem Versicherungswesen.

Folgende Verbesserungen wurden direkt im aktuellen Scrum Guide verankert:

• Anforderungen sind lebende Dokumentation, die während des gesamten Lebenszyklus von Produkten zu aktualisieren ist
• Anforderungen müssen in geordneter Weise im Product Backlog vorgehalten werden, um die Verfeinerung von in Kürze implementierten User Stories zu erleichtern
• Das Product-Backlog ist  die einzige Anforderungsquelle für alle Änderungen am Produkt [Single Source of Truth]