User Stories beschreiben eine Funktion einer Software aus der Perspektive einer Endnutzer:in. Das Ziel ist nicht, ein Feature zu beschreiben, sondern den Mehrwert bzw. das Ziel der Endnutzer:innen darzustellen (Rasmusson, 2010b). Dabei wird typischerweise diese Satzschablone WHO-WHAT-WHY verwendet.
[Titel]
Als [Wer?],
möchte ich [Was?],
damit [Wozu?].
Dateien kopieren
Als Datenerfasserin,
möchte ich Dateien duplizieren,
damit ich Daten schneller erfassen kann.
Table of Contents
Die drei Aspekte von User Stories, die besonders dafürsprechen, sich wirklich mit Liebe der Formulierung zu widmen, sind:
- User und dessen Ziele stehen im Mittelpunkt
- Es geht primär um das Ziel der Userin und den zu generierenden Mehrwert
- Ständige Innovation fördern
- Als Tool helfen User Stories den Entwickler:innen den fachlichen Kontext zu verstehen und lassen gleichzeitig den nötigen Raum für ständige Innovation. Im obigen Beispiel können nun die Entwickler:innen Möglichkeiten finden, WIE die Story umgesetzt wird und werden nicht von Feature-Beschreibungen begrenzt. User Stories helfen also, wenn sie gut formuliert sind, das WAS vom WIE zu unterscheiden und bieten durch das WER und WARUM/WOZU den notwendigen Kontext.
- Zusammenarbeit und Kommunikation fördern
- Als Kommunikationstool in Team-Meetings fördern User-Stories das gemeinsame Diskutieren von User-Problemen und Lösungen.
Wo werden User Stories verwendet und wo nicht?
User Stories werden von vielen agilen Teams verwendet, um Wünsche und Bedürfnisse von Nutzer:innen zu beschreiben und um diese besser einschätzen zu können. Besonders im Rahmen von Scrum und Kanban werden User Stories verwendet. Das Team kann so den Kontext der Funktion verstehen. Dabei geht es immer um die Frage: „Welchen Nutzen hat diese Softwarefunktion für den Endnutzer?“ (Rasmusson, 2010b). Hier können auch interne Abnehmer:innen die in der User Story beschriebenen Endnutzer/Kunden sein.
User Stories können auf Karten, Haftnotizen oder auch innerhalb einer Projektmanagement-Software wie z.B. Jira geschrieben werden.
Die produktverantwortliche Person schreibt meist die User-Stories während der Product-Discovery. Auch die anderen Teammitglieder können User Stories schreiben, doch zumindest laut Scrum Guide ist der Product Owner (Produktverantwortliche Person im Scrum) für die Qualität der Stories rechenschaftspflichtig.
Einerseits dienen User Stories (oft kombiniert mit Prototypen und Akzeptanzkriterien) den Tests und Experimenten während der Discovery. Andererseits dienen sie während der Delivery als Erinnerung an die Entscheidungen, die im Team gemeinsam getroffen wurde. Sie sollten nicht als fixe Anforderungsbeschreibung gesehen werden.
User Stories schreiben in 3 Schritten
User Stories werden in drei Schritten verfasst:
- Persona/Kundentyp – WER: Beschreibung des Endnutzers/der Endnutzerin
- Persona identifizieren durch Untersuchung der Zielgruppe während der Discovery
- Wer soll erreicht werden?
- Welche Merkmale wünscht sich diese Person?
- Was sind psycho- und demografische Merkmale dieser Person?
- Beispiel: Heike, eine Datenerfasserin, die täglich viele Dateien anlegt
- Mehr zu Personas: siehe Personas
- Bedürfnis/Anforderung – WAS: Ziel der Softwarefunktion; was die Funktion erreichen soll für den Nutzer/die Nutzerin
- Wie nutzen diese Personen diese Funktion und warum?
- Was will die Person erreichen?
- Wie hilft die Funktion dabei?
- Nicht die spezifische Funktion beschreiben, sondern das, was erreicht werden soll.
- Beispiel: eine fertige Datei als Vorlage nutzen und sie kopieren und editieren
- Zweck – WARUM und WOZU: Ziel des Nutzers/der Nutzerin bei der Verwendung der Funktion
- Mehrwert der Funktion
- Welches Problem soll gelöst werden?
- Wie passt dies zu den übergeordneten Zielen des Unternehmens
- Beispiel: Steigerung der Effizienz durch schnellere Dateneingabe
Achtung: Auf die Beschreibung des WIE wird unbedingt
verzichtet. So etwas wie „brauche ich einen blauen Kopierbutton oben rechts…“ sollte in einer User Story also nicht vorkommen.
User Stories formulieren und prüfen
Es gibt zwei bekannte Prinzipien, nach denen User Stories formuliert und geprüft werden können: die INVEST-Regel und die „3 Cs“.
Die INVEST-Regel
Neben den 3 Cs gilt die INVEST-Regel (nach dem Erfinder der User Stories Bill Wake) als Grundlage für die Formulierung von User Stories. Das Akronym INVEST steht für Independent, Negotiable, Valueable, Estimable, Small und Testable (Eid, 2022). Näher bedeuten die INVEST-Kriterien:
- Independent (Unabhängig)
- In sich abgeschlossen – end to end durch alle ebenen der Architektur
- Nicht von anderen Aufgaben abhängig
- Steht für sich
- Frei priorisierbar
- Können aus dem Product Backlog entfernt werden, ohne das restliche Product Backlog zu sehr zu beeinflussen
- Negotiable (Verhandelbar)
- Lässt Spielraum für Diskussionen, wie umfassend oder abgespeckt die Umsetzung (das WIE) sein soll
- User Stories sollen keine Lösungen vorgeben
- Sie sollen den Kontext des Problems und des Bedürfnisses des Endnutzers beschreiben
- Valueable (Wertvoll)
- Stellt für sich einen Wert dar
- MUSS einen Wert für das Business haben
- Eine Wertsteigerung im zu entwickelnden Produkt wird durch die Umsetzung erzielt
- Estimable (Abschätzbar)
- Kann geschätzt werden
- Erst danach wird sie ins Sprint Backlog aufgenommen
- Small/Sized appropiately (Überschaubar)
- So groß, dass sie im Rahmen eines Sprints umgesetzt werden kann
- Testable (Prüfbar)
- Für sich genommen testbar
- Dazu werden Akzeptanzkriterien definiert
- Diese werden durch Entwickler:in und PO/Product Manager geprüft
Die INVEST-Regel wird oft als Komponente der Definition of Ready (DoR) erwähnt.
Die „3 Cs“
Ron Jeffries beschrieb bereits 2001 in einem seiner Blogartikel die 3 Cs für User Stories. Sie gelten neben den INVEST-Regeln als eine der Grundregeln für die Erstellung von User Stores.
- Card
- Kurz und prägnant, so dass sie auf eine Karte passt
- Soll zeigen, was erreicht werden soll
- Reicht der Platz nicht aus, ist die User Story zu groß oder zu lang beschrieben
- Alles, was über die Karte hinaus geht, soll in persönlichen Gesprächen mit dem Team abgestimmt werden
- Conversation
- Jede User Story soll eine Konversation fördern – und zwar soll jede Story mindestens einmal zwischen Team und Kunde besprochen werden – bzw. Kunde soll den Input liefern
- Nicht nur auf der Karte notieren und dann ablegen, eher sogar mehrfach besprechen in Spezifikations-Workshops, beim Schätzen und in der Sprint-Planung
- Confirmation
- Es werden verbindliche Akzeptanzkriterien für die User Story vereinbart
- Akzeptanztests können implementiert werden, um die Implementierung entsprechend der Akzeptanzkriterien sicherzustellen (siehe auch Akzeptanzkriterien)
Die Akzeptanzkriterien können beispielsweise mit der Gherkin-Beschreibungssprache im Rahmen des Behavior Driven Developments umgesetzt werden.
Übung: User Story formulieren in Kleingruppen
Bildet Paare und formuliert für ein aktuelles Thema aus eurem Arbeitsumfeld eine User Story und beachtet dabei besonders darauf, das WARUM sinnvoll und passend formulieren.
Es sollte sich, wenn möglich, nicht um ein fiktives Beispiel handeln, um Komplexität nicht künstlich zu reduzieren und einen optimalen Lerneffekt zu erzielen.
Stellt euch danach eure User Stories vor und diskutiert sie.
(Auch als Einzelübung.)
Job Stories
Als Alternative zu User Stories haben sich die sogenannten Job Stories entwickelt. Dabei wird der Fokus weg von einer Person hin zu einer Situation gelenkt (Cohn, 2022). Hier geht es um den „Job-to-be-done“.
Job Stories können dann eine Alternative zu User Stories sein, wenn die User:innen einen Produktes sich in ihren Zielen bei der Nutzung des Produkts nicht maßgeblich unterscheiden. Wenn ich beispielsweise in einem Online-Shop meinen Warenkorb leere, dann soll wahrscheinlich das Verhalten gleich sein, egal welche Art von User:in ich bin.
Hier ist die Satzschablone wie folgt:
Titel
Wenn [Situation],
möchte ich [Motivation],
so kann ich [Ergebnis].
Beispiel:
Wenn ich den Warenkorb leere,
möchte ich gefragt werden, ob ich wirklich den Warenkorb leeren will,
damit ich nicht versehentlich alle Elemente aus dem Warenkorb entferne.
Sowohl bei der Verwendung von User Stories als auch bei Job Stories wird ein direkter Nutzen für die Userin beschrieben.
Technische Stories
Bei der Softwareentwicklung werden üblicherweise auch solche Dinge umgesetzt, die eher technisch erforderlich sind und keinen direkten Nutzen für User:innen haben. Hier kann man sich sicherlich umständlich einen Nutzen für User:innen herleiten und so eine User Story formulieren. Das Ziel ist allerdings hier eher, die technische Aufgabe so zu beschreiben, dass die Business-Seite (Product Owner) verstehen kann, warum und wozu die Änderung notwendig ist und dann die Aufgabe im Backlog entsprechend priorisieren kann (Lieder, 2011).
Hier ist also die Kommunikationsrichtung umgekehrt: die Entwickler:innen formulieren die technische Story so, dass die Business-Seite den Kontext versteht und gemeinsam darüber diskutiert werden kann.
Die zu erledigende Aufgabe bildet hier das WAS, also den zweiten Teil der Technischen Story. Beispiel: „auf eine andere Datenbank wechseln“.
Nun muss noch beantwortet werden, WARUM/WOZU das nötig ist und WER davon profitiert.
Das WER kann auch einfach die Applikation, der Systembetrieb oder ein:e (zukünftige) Entwickler:in sein. Für das WARUM/WOZU muss eine Aussage gefunden werden, die es der Business-Seite möglich macht, die Story zu priorisieren.
Beispiel:
Als Entwickler:in,
möchte ich die Datenbank bis Ende des Jahres auf xy umziehen,
damit weiterhin Support verfügbar ist.