Das Rahmenwerk älterer Scrum Guides (vor 2011) wurde mit "User Stories" als Hilfsmittel zur Erhebung und Pflege von Anforderungen in agilen Projekten ergänzt. Es hat sich seitdem zur Entwicklung von mehr und weniger komplexen Produkten bewährt, solange die damit verbundenen Geschäftsprozesse und das Netzwerk verbundener Produkte überschaubar ist.
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 den vormsld 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.
