Das Rahmenwerk älterer Scrum Guides (vor 2011) wurde üblicherweise mit "User Stories" als Hilfsmittel zur Erhebung und Pflege von Anforderungen in agilen Projekten ergänzt und zur Entwicklung von mehr und weniger komplexen Produkten eingesetzt. Diese Kombination erwies sich später als eingeschränkt im Vergleich zu den weiterhin praktizierten Techniken für professionelles Anforderungsmanagement. Auf Grund der großen Popularität und Vorteile "schlanker" Vorgehensweisen, wollte aber kaum jemand zu den bewährten, aber 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 Umsetztung 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 zunächst in einem Vorbereitungs-Sprint gesammelt, und später laufend ergänzt, verfeinert und unter Umständen auch wieder verworfen. Der Product Owner kann während laufenden Sprints die Dokumentation von User Stories aus Workshops auch an andere Scrum Rollen delegieren, ohne jedoch die Verantwortung für die 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 <Ziel> [,so dass <Grund>]
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-Analye, Anwendungsfall-Analyse, Schnittstellen-Analyse und Prozess-Analyse berücksichtigt. Es fehlt zudem die Möglichkeit, Abläufe oder fachliche Beziehungen zu fordern.
Das Akronym INVEST hilft beim verinnerlichen folgender Merkmale einer guten Story:
- [Independent] Jede Story muss eindeutig identifizierbar sein, dazu wird überlicherweise eine Nummer vergeben. Darüber hinaus sollen möglichst wenig Abhängigkeiten zu anderen Stories bestehen, oder es sind entsprechende Hinweise vorzusehen.
- [Negotiable] die beschriebene Funktionalität soll keine unnötigen Vorgaben und Annahmen für die Umsetzung beinhalten, und so formuliert sein, das ausreichend Spielraum für eine effiziente Realisierung bleibt. Deshalb sollten Stories nicht auf konkretes GUI Design, konkretes Schnittstellendesign oder konkrete technische Datenstrukturen verweisen, außer diese sind durch nicht funktionale Anforderungen vorgeben.
- [Valuable] Der geschäftliche Wert der beschriebenen Funktionalität wird ggfs. erläutert, wenn er nicht unmittelbar ersichtlich ist. Hinweise auf den Wert der Möglichkeit, Geschäftsobjekte anlegen, ändern oder entfernen zu können (CRUD) sind in der Praxis z.B. überflüssig.
- [Estimateable] Die mit der geforderten Funktionalität verbundene Arbeit muss vor dem Hintergrund des gemeinsam erarbeiteten Wissens schätzbar sein.
- [Small] klein - vom Team in ein bis zwei Tagen umsetzbar.
- [Testable] Testbar - vor dem Hintergrund des gemeinsam erarbeiteten Wissens muss das Team für die mit einer Userstory verbundenen Akzeptanzkriterien ausreichend genaue Tests erstellen können (wenn möglich automatisiert!).
Es ist zudem gestattet, schriftlich "Akzeptanzkriterien" zu dokumentieren, jedoch ohne konkrete Testdaten und Testszenarien. Derartige Information soll wenn möglich nur mündlich und über wohl strukturierten Code ausgetauscht werden.
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.
Das zuvor beschriebene Vorgehen weist Mängel aus Sicht eines "agiles Anforderungsmanagements" auf. Streng genommen fehlen bei diesem Vorgehen reproduzierbare Anforderungen, mit Ausnahme flüchtiger mündlicher Vereinbarungen und einer unsortierten Liste von Überschriften. Abhilfe schaffen z.B. "Erweiterte User Stories" und andere Techniken für das agile Anforderungsmanagement.
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]