Bei einer User Story handelt es sich um eine einfache Beschreibung einer Eigenschaft (eines sogenannten Features). Sie wird aus Sicht des Endnutzers verfasst. Also aus der Perspektive einer Person, die ein neues Produkt bzw. eine neue Dienstleistung oder einen Teil davon braucht. In der Regel handelt es sich um den (End-)Kunden. Eine User Story hat den folgenden simplen Aufbau:
Wer? Was? und Warum?
Als (Kunde) brauche ich (Beschreibung dessen, das entwickelt werden soll), damit ich (Beantwortung der Frage, weshalb das Produkt/ die Dienstleistung angeboten werden soll).
Die einzelnen User Stories werden auf Zettel (z.B. Post-Its) geschrieben. Dann hängt man sie auf das sogenannte Product Backlog. Hier kann sich das gesamte Team jede einzelne User Story anschauen. Zweck des Ganzen: Es wird deutlich, welche Arbeiten zu erledigen sind, wieviel Zeit sie jeweils in Anspruch nehmen und in welcher Reihenfolge die Aufgaben angegangen werden sollen.
Die Vorteile von User Stories
Einer der Vorteile von Agile User Stories besteht darin, dass sie unterschiedlich Tief auf die Materie eingehen können. Mittels einer User Story kann ein komplettes Marketingprojekt genauso gut beschrieben werden wie ein spezifischer Bestandteil beispielsweise einer Marketingveranstaltung. Eine große User Story wird auch als „Epic” bezeichnet. Sie kann in Dutzende kleinere User Stories unterteilt werden, damit die Übersicht nicht verlorengeht. Die kleineren User Stories gehen auf Einzelheiten des jeweiligen Aspekts ein.
Beispiel:
Die Leitung einer Marketingabteilung möchte sich in dem Tool, das sie zur Erfolgsmessung nutzt, Feiertage anzeigen lassen können. So soll eine Analyse der Ergebnisse dazu gefahrener Marketingkampagnen ermöglicht werden. Im nächsten Schritt geht es um zusätzliche Details wie:
- Diese Funktionalität muss in jedem Fall für die folgenden Feiertage verfügbar sein: Weihnachten, Ostern, Muttertag, Vatertag.
- Ich möchte mir eine bestimmte Zahl von Tagen vor oder nach dem Feiertag anzeigen lassen können.
Anhand solcher Details lässt sich eine große User Story in einzelne User Stories zerlegen. Diese können im Anschluss in zu erledigende Arbeiten aufgeteilt und auf einem Sprint Backlog angebracht werden.
Der Product Owner ist für die Erstellung eines Product Backlog aus den User Stories verantwortlich. Das bedeutet nicht, dass nur er sie schreibt. Er darf das Verfassen der User Stories auch an Teammitglieder delegieren.
Es ist wichtig, dass alle Beteiligten wissen: Es geht nicht darum, wer eine User Story schreibt und wie das geschieht. Viel wichtiger ist, dass sowohl mit dem Product Owner als auch mit dem Scrum Team ausführlich darüber diskutiert wird. Denn aus jeder User Story werden die Arbeiten abgeleitet, die tatsächlich erledigt werden müssen, damit das angestrebte Ziel erreicht werden kann.
Wann wird eine User Story geschrieben?
User Stories werden das gesamte Agile Projekt hindurch geschrieben. Es empfiehlt sich, zu Beginn des Projekts einen Story Writing Workshop abzuhalten. Jedes Teammitglied sollte daran teilnehmen. Ziel ist die Erstellung eines vollständigen Product Backlog, der ein (Teil-)Produkt umfassend beschreibt. Oft werden hierfür mindestens die beiden ersten zwei Sprints genutzt. Bei manchen User Stories handelt es sich in dieser Phase um Epics. In einem späteren Schritt wir jede User Story in kleinere überschaubarere aufgeteilt. Das Team hat die Möglichkeit, das Backlog auch während des Sprints um zusätzliche User Stories zu erweitern.
Zusammenfassung
User Stories ähneln traditionellen Anforderungsplänen. Sie beschreiben die Funktionalität eines neu zu entwickelnden Produktes oder einer neuen Dienstleistung. Jede User Story dient als Ausgangspunkt für Gespräche innerhalb des Teams. Daraus ergeben sich die tatsächlichen Aufgaben samt dazugehöriger Zeitressourcen. Sie werden auf einem Sprint Backlog angebracht.
