Eine User Story beschreibt eine bestimmte Funktionalität, die für den Benutzer des Systems einen wahrnehmbaren Wert hat. Jede User Story sollte so einfach wie möglich und aus Sicht des Benutzers beschreiben, was der Benutzer mit der Funktionalität erreichen will.
Der Fokus hierbei liegt auf den Fragen:
- Für wen ist das Feature gedacht?
- Was will derjenige damit erreichen können?
- Warum will er das Ergebnis erreichen?
Eine User Story beschriebt die funktionale Anforderung aus Kundensicht, sie beschreibt nicht das WIE. Sie ist eine knappe Darstellung der Anforderung, die maßgeblich den Nutzen hervorhebt. Der folgende Leitspruch ist hierbei meines Erachtens sehr wertvoll und richtig, wenn es darum geht gute User Stories zu schreiben:
Gib mir einen Nutzen und ich gebe dir die Funktion dazu, die Du dir wünschst.
User Stories werden in folgender Form geschrieben:
Als <Rolle>,
Möchte ich <Ziel/Wunsch>,
Um <Nutzen>
As a <role>,
I want to <goal/desire>
So that <benefit>
Hilfreich ist es mit den Fragen “Wer” und “Wozu” zu beginnen:
“Als regelmäßiger Kunde des Online-Buchhandels
Möchte ich …,
Um mich für oder gegen den Kauf eines Buches entscheiden zu können.”
Dieser Teil der User Story alleine beschreibt schon für jeden klar ersichtlich, was die Intension des Anwenders ist und würde im Notfall schon ausreichen die Anforderung grob zu beschreiben. Die Art und Weise den Kundennutzen zu erreichen ist dann die Funktion, die den Nutzen dann tatsächlich bringt. Beispielsweise:
“Als regelmäßiger Kunde des Online-Buchhandels
Möchte ich Bewertungen anderer Käufer lesen,
Um mich für oder gegen den Kauf eines Buches entscheiden zu können.”
Akzeptanzkriterien ergänzen eine User Story
Ergänzt wird eine User Story immer durch mindestens ein Akzeptanzkriterium. Sie definieren die Rahmenbedingungen unter denen der Anwender die User Story für akzeptabel hält.
Akzeptanzkriterien machen eine User Story testbar. Dies bedeutet, dass die User Acceptance Tests (Anwendertests) genau die Akzeptanzkritereien prüfen. Sie bilden also die Grundlage dafür Tests für die User Stories zu schreiben und dann auch durchzuführen.
Es ist sinnvoll ein gutes Maß an Akzeptanzkriterien zu haben. Meine Erfahrung zeigt hier, dass um die fünf Akzeptanzkriterien oftmals ein guter Richtwert sind. Bei wesentlich mehr Akzeptanzkriterien ist es sinnvoll die User Story ggf. in zwei oder mehr User Stories aufzuteilen.
Eine User Story ist ein Anlass zur Konversation. Das bedeutet, eine gewisse Unstabilität in der User Story wird benötigt, damit eine Konversation, ein Dialog entstehen kann. Eine gewisse Unschärfe , die nicht verschleiert ist hilfreich. Nicht der Nebel, der durch schöne Worte und vermeintliche Vollständigkeit glänzt: “Alles steht hier geschrieben, genau das brauchen wir so wie es formuliert wurde.” Vielmehr sollte der Nebel dazu anregen zu Fragen: “Sollen wir lieber links oder rechts gehen, ich bin mir gerade nicht ganz sicher.” Software-Entwicklung ist zu großen Teilen ein Kommunikationsproblem und zu genaue Anweisungen verstärken dieses Problem. Bei zu genauen Anweisungen fragen wir nicht mehr nach, die Kommunikation versiegt. Oftmals führen auch zu genaue Anweisungen dazu, dass genau diese auch implementiert werden, obwohl sie gar nicht so gemeint waren.
Beispiele für Akzeptanzkriterien können sein:
- Erwartete Fehlermeldungen
- Datenformate
- Validatoren für Eingabefelder
- Werte/Wertgrenzen
- Performanzangaben
- u.v.m.
Das folgende Beispiel soll dies etwas verdeutlichen:
„Als Schulungsteilnehmer,
Möchte ich meinen Trainer bewerten können,
Um ihm ein qualifiziertes Feedback zu seiner Schulung zu geben, damit er die Chance hat seine Schulung zu verbessern.“
Akzeptanzkriterien:
- Das Feedback kann innerhalb von 30 Sekunden gegeben werden
- Die Aspekte Moderation, Inhalt, Detailtiefe, Bewirtung können bewertet werden.
- Die Felder des Schulungstitels und Referenten müssen nicht gesondert gewählt werden sondern sollen vorbefüllt sein
- Das Feedback kann nach Wunsch anonym gegeben werden
In diesem Beispiel ist zu erkennen, dass keinerlei Vorgaben für die Umsetzung gemacht werden. Theoretisch kann diese User Story mit Hilfe eines vorgedruckten Zettels, der am Ende der Schulung ausgeteilt wird erfüllt werden. Andererseits können eine WebSeite, deren URL in der Schulung bekannt gegeben wird, via EMail verteilt wird, oder eine App für das Handy diese User Story gleichermaßen erfüllen. Welche Art der Umsetzung hier sinnvoll ist hängt von den Rahmenbedingungen ab, die für das Produkt gelten, das umgesetzt werden soll. Und dies ist der bereits angedeutete Nebel, der die Kommunikation zwischen Product Owner/Anwender und Entwicklern anregen soll, um gute Lösungen im Sinne des Anwenders zu finden.
Mockups können helfen
Ein Bild sagt mehr als tausend Worte.
Meine Erfahrung zeigt, dass es sehr hilfreich ist zu User Stories ein Mockup beizufügen. Mit Mockup meine ich hier eine schematische Skizze, die darstellt, wie der Anwender sich die Umsetzung der User Story optisch vorstellt. Diese bilden oft eine gute Diskussionsgrundlage und vermitteln einen ersten Eindruck, wie eine Umsetzung aussehen könnte.
Achtung: Wichtig ist hier für alle Beteiligten klarzustellen, wie final dieses Mockup ist. Da ein Mockup mehr als tausend Worte sagt sollte es ausschließlich korrekte Dinge darstellen und jedem Beteiligten bewusst sein, wie die Darstellung zu interpretieren ist. Folgende Anekdoten aus dem „echten Leben“ verdeutlichen, was ich hiermit meine:
- Das Mockup stellte einen Screenshot eines anderen Systems dar. Ein Teil dieses Screenshots bezog sich auf die User Story und sollte umgesetzt werden, ein anderer Teil hatte mit der User Story nichts zu tun, war aber im Screenshot noch enthalten. Hier wollte man sich den Aufwand sparen das Bild nochmal zu überarbeiten. Also wurde ergänzend zur User Story eine Notiz beigefügt: „Nur den mittleren Teil beachten, die anderen Teile ignorieren“. Was ist natürlich geschehen? Umgesetzt wurde genau das, was im Bild zu sehen war und die Notiz wurde gänzlich ignoriert – Bilder sind bedeutender als Text.
- Als Mockup wurde eine Grafik beigefügt, die als „Gitternetz“ schematisch darstellte, wie das Menü einer Anwendung strukturiert werden soll. Schwarze, dicke Linien auf weißem Grund – eine Skizze eben. Die Intension des Product Owners war eine schematische Darstellung und die Erwartung, dass das allgemein gültige Design dann in der Umsetzung auf das Menü angewandt wird. Bei der Umsetzung wurde dies aber als exakte Designvorgabe interpretiert und obwohl dies nicht in das optische Design der Anwendung passte, tatsächlich mit dicken, schwarzen Linien und weißem Grund umgesetzt.
Was sind Product-Backlog-Items (PBIs)?
Product-Backlog-Items (PBIs) sind die Anforderungen, die im Product-Backlog verwaltet und in den Sprints umgesetzt werden. Hierzu zählen die Anforderungen (User Stories), Fehler (Bugs) oder auch Impediments (Hindernisse).
Ein Use Case ist keine User Story
Use Cases haben auch ihre Daseinsberechtigung und sind auch zweckmäßig, sind aber nicht mit User Stories zu verwechseln.
Userstories sind kein Use Case!!
Bei Use Cases geht es darum, Interaktionen von Nutzern mit einem System so zu beschreiben, dass das Ziel der Nutzer klar wird. Nutzer können dabei sowohl Menschen als auch andere technische Systeme sein.
Als Kunde eines Online-Buchhandels ist es z.B. mein Ziel, ein Buch zu kaufen.
Welche Interaktionsschritte sind nun notwendig, um das Ziel zu erreichen? Im Gutfall etwa folgende:
- Kunde findet Buch.
2. Kunde legt Buch in Warenkorb.
3. Kunde geht zur Kasse.
4. Kunde gibt seine Adressdaten und Zahlungsdaten ein.
5. Kunde bestätigt Kauf.
6. System zeigt bestätigten Kauf und versendet Email mit Kaufbeleg an Kunden.
Je nach Einsatzzweck kann man Use Cases auch sehr viel detaillierter beschreiben, insbesondere ist natürlich auch noch eine Beschreibung der Fehlerfälle notwendig.
Was sind nun Unterschiede zwischen Use Cases und User Stories?
Traditionell werden Use Cases oft sehr detailliert beschrieben, um als Anforderungsspezifikation oder Dokumentation der Systemfunktionalität benutzt zu werden. User Stories werden dagegen bewusst nicht als Dokumentationsinstrument eingesetzt, sondern lediglich als Basis, um persönlich über Anforderungen zu reden.
User Stories werden als Planungsinstrument eingesetzt, das heißt so lange „kleingeschnitten“, bis sie in einem festgelegten Zeitraum einer Iteration umgesetzt werden können. Dadurch sind sie klein und kompakt, im Vergleich zu Use Cases mangelt es ihnen aber oft an Kontextinformationen.
