Wie schreibe ich eine User Story?
26. September 2011 2 Kommentare
User Stories scheinen sich zu einer “State of the art”-Methode zur Formulierung von Anforderungen entwickelt zu haben. Kaum ein Buch über agile Softwareentwicklung, dass nicht auf diese Form der Beschreibung von Anforderungen verweist. Aber: Wie schreibt man eigentlich eine User Story?
Erst einmal zur Beruhigung: User Stories schreiben ist wie Fahrad fahren! Am Anfang ist es ungewohnt und fühlt sich seltsam an. Nach ein paar Versuchen läuft es dann aber wie von alleine und man verlernt es nie!
Nach über einem Jahr der Arbeit mit User Stories kann ich mir kaum noch vorstellen, wie ich mit meinen Teams vorher Anforderungen formuliert habe.
Grundsatz: Formulierung aus Sicht des Nutzers
Ein wichtiger Grundsatz bei User Stories ist, dass sie aus der Sicht eines Anwenders geschrieben werden. Daher werden sie auch frei von technischem Schnickschnack gehalten. Jeder, der am Projekt beteiligt ist, also auch jeder Anwender, sollte sie optimalerweise verstehen können. Hingegen sollte das Entwicklungsteam tolerant gegenüber der Fachsprache der Anwender sein.
3 Bestandteile einer User Story
Eine User Story setzt sich mindestens aus den folgenden drei Elementen zusammen:
- Einem kurzen, prägnanten Namen.
- Einer kurzen Beschreibung der Anforderung.
- Mehreren Akzeptanzkriterien, die die Details ausdrücken und dokumentieren und bei der Klärung helfen, ob eine Story wirklich abgeschlossen ist.
Nach wie vor hilft diese einfache Satzkonstruktion beim Einstieg in das Schreiben einer User Story:
Um (den folgenden Nutzen zu erhalten), möchte ich als (Anwendertyp) (diese Funktion).
Schauen wir uns die drei Teile dieses Satzes noch einmal etwas genauer an.
Name
Eine kurze, prägnante Benennung, die sich die Teammitglieder und die anderen Beteiligten gut merken können. Am besten ist sie so, dass jeder etwas damit anfangen kann, wenn jemand sagt “Wir sollten noch xy umsetzen”. Wir die Anmeldung an einem System kann also die Bezeichnung “Anmeldung” ausreichend sein, wenn das Team versteht, was damit gemeint ist.
Beschreibung
Wer möchte eigentlich etwas?
Es ist möglichst klar darzustellen, von wem die Anforderung überhaupt kommt. Vermutlich am häufigsten anzutreffen sind User Stories mit dem Anwendertyp “Benutzer”. Es kann jedoch deutlich spezifischer zum Ausdruck gebraucht werden, um welchen Benutzer es sich handelt. Z.B. durch eine Ergänzung wie “als Benutzer mit einem Twitter-Account”. Das ist schon ein ganzes Stück spezifischer und hilft allen Beteiligten einzuschätzen, wie groß die Nutzergruppe ist und woher ihr Wunsch kommt.
Wenn das Team mit Personas arbeitet, kann es sinnvoll sein, die bestimmte Persona zu nennen, die im besonderen diese Anforderung hegt.
Warum will er das tun, welchen Nutzen will er erzielen?
An dieser Stelle steht der zu Grunde liegende Nutzen, der erreicht werden soll. Die Idee ist dabei, dass die anschließend beschriebene Funktionalität aus dem Nutzenstreben abgeleitet sein muss. Ein Benutzer will sich z.B. nicht als Selbstzweck bei einer Softwareanwendung anmelden, sondern macht diese nur, um die Kernfunktionen der Software anschließend nutzen zu können.
Durch welche Funktionalität will er den Nutzen realisieren?
In diesem Teil wird dargelegt, welche Funktionalität zur Realisierung des Nutzens implementiert werden soll.
Insgesamt könnte die Beschreibung einer User Story damit wie folgt aussehen:
Um (die Software nutzen zu können), möchte ich mich (als Benutzer mit einem Twitter-Account) (mit meinen Twitter-Zugangsdaten anmelden).
User Stories können einen sehr unterschiedlichen Grad an Genauigkeit annehmen. Dies hängt auch damit zusammen, wie nah oder weit die Umsetzung der Anforderung ist. Es kann sein, dass die Lösung der User Story noch weitgehend offen gehalten werden soll, oder aber es ist schon eine Entscheidung für eine konkretere Umsetzungsvariante gefallen. Wurde etwa bereits festgelegt, dass in unserer Beispiel-Story die Anmeldung per Twitter-Zugangsdaten mit Hilfe des Protokolls OAuth erfolgen soll, könnte die User Story wie folgt konkretisiert werden:
Um (die Software nutzen zu können), möchte ich mich (als Benutzer mit einem Twitter-Account) (mit meinen Twitter-Zugangsdaten über das sichere Authorisierungsprotokol OAuth anmelden).
Akzeptanzkriterien
Wie kann festgestellt werden, ob die User Story entsprechend den Anforderungen umgesetzt wurde? Die Akzeptanzkriterien spielen dabei eine besondere Rolle. Sie beantworten die Frage, was getestet werden soll. Eine gute Hilfsregel für die Formulierung von Akzeptanzkriterien ist, dass sie mit “Teste…” anfangen sollten. Beispiele für unsere obige Story könnten sein:
- Teste die Eingabe eines ungültigen Benutzernamens…
- Teste die Eingabe eines ungültigen Passworts
- Teste die Eingabe eines gültigen Benutzernamens und eines gültigen Passworts
- …
Wie stelle ich sicher, dass das Team die User Stories versteht?
Zunächst kann eine gewisse Unsicherheit vorhanden sein, ob das Entwicklungsteam die User Stories in der Form akzeptiert. Hier ist es aber wie mit vielen anderen Dingen in der agilen Softwareentwicklung. Es gehört Mut dazu, Dinge auszuprobieren und sich einzugestehen, dass am Anfang nicht alles rund läuft. Inspect and adapt. Nach ein paar Wochen der Arbeit mit User Stories haben dann alle Beteiligten eine gemeinsame Vorstellung davon entwickelt, wie umfangreich, detailiert und sauber die User Stories ausgearbeitet werden müssen. Das funktioniert am besten, wenn darüber hinaus regelmäßige Backlog Grooming-Sitzungen durchgeführt werden, in denen mit dem Entwicklungsteam und Anwendern zusammen an den Stories gearbeitet wird.
Ergänzende Beschreibungen, Mock-ups, Wireframes,…
Ergänzt werden können diese drei Grundelemente einer User Story durch weitere Informationen, die dem Entwicklungsteam dabei helfen zu verstehen, wie die Umsetzung erfolgen soll. Das können ergänzende Beschreibungen, Mock-ups, Wireframes, Scribbles … you name it … sein. Das wichtigste ist, dass diese das gemeinsame Verständnis der Anforderung unterstützen. Sie sollten aber niemals die persönliche Kommunikation zwischen den Beteiligten ersetzen!
Weiterführende Informationen:
- User Stories: Anforderungen aus Nutzersicht dokumentieren
- Userstories: Volle Konzentration auf den Kundennutzen
- Die besten Ressourcen zu User Stories
- Card, Conversation, Confirmation: Die drei C’s einer User Story
- Buch Review: “User Stories Applied” von Mike Cohn
Foto: kmlz
Der Sprint neigt sich dem Ende zu und das Review-Meeting, welches im Rahmen jedes Scrum-Sprints zur Präsentation der Arbeitsergebnisse durchgeführt wird, steht an. Spätestens jetzt zeigt sich, was das 
Um Herausforderungen in der Bedienung von Software herauszufinden werden von Usability-Experten unter anderem Usertests durchgeführt. Dabei werden repräsentative Anwender dabei aufgezeichnet, wie sie zuvor festgelegte Aufgaben mit Hilfe der Software erledigen. Solche Tests ermöglichen es Experten einen Großteil der bei Nutzern auftretenden Fehler zu identifizieren. Werden solche Tests frühzeitig im Entwicklungsprozess durchgeführt, können somit Usabilityfehler vor Auslieferung der Software noch behoben werden.
Es ist unheimlich spannend, Softwareentwicklungsteams bei den ersten Sprints eines neuen Scrum-Projekts zu beobachten. Es ist eine intensive Zusammenarbeit gefordert, um als Team erfolgreich zu sein.
Einfachheit ist vielfach Trumpf. “Einfache Pläne, die ausgeführt werden, sind besser als komplexe Pläne, die noch in Planung sind”, 
