Die erste große Herausforderung die man beim Schreiben hervorragender User-Stories hat ist, herauszufinden, was man schreibt. Doch wenn man das erst mal weiß, steht man vor dem nächsten Problem: Wie strukturiert man seine User-Story?
In diesem Blog-Eintrag erfahren Sie, nach welcher Methodik wir in der Regel User-Stories schreiben.
Aufbau einer hervorragenden User-Story
Eine hervorragende User-Story deckt möglichst viele offene Fragen ab, die ohne geklärt zu sein bei der Entwicklung oder beim Test unnötige Schleifen erzeugen.
Dabei ist es wichtig die fachliche Domäne gut abzudecken sowie technische Aspekte zu berücksichtigen. Eine gut strukturierte User-Story lässt keine Missverständnisse zu, ist einfach zu lesen und zu verarbeiten.
Für uns hat sich folgende Struktur bewährt:
- Einleitungssatz: Erklärt in einem kurzen prägnanten Satz, idealerweise aus Sicht des Users geschrieben, was der Zweck der Story ist.
- Akzeptanzkriterien: Beschreibt, was das System nach der Umsetzung der Story kann.
- Scope: Eine Auflistung aller relevanten Aspekte, die es bei der User-Story zu berücksichtigen gilt.
- 1-N Details zum Scope: Details für jeden relevanten Aspekt, der unter Scope aufgelistet wurde.
- Out-of-Scope: Beschreibt, was nicht Teil der User-Story ist.
- Umsetzungsdetails: Platzhalter für technische Details, die während technischer Verfeinerungsrunden aufgedeckt und ergänzt werden.
Im Sinne des Beispiels könnte eine User-Story für einen Login z.B. so aufgebaut sein:
Als Benutzer möchte ich mich bei der Website anmelden können, damit ich Zugriff auf die Website habe.
Akzeptanzkriterien
Scope
- Implementierung der Oberfläche
- Verifizierung der Anmeldung
- Darstellung der Seite nach erfolgreicher Anmeldung
- Fehleranzeige im Falle einer fehlgeschlagenen Anmeldung
- Gültigkeit der Anmeldung
Implementierung der Oberfläche
- Es wird die Login-Maske entsprechend des folgenden Designs entworfen: …
- …
Verifizierung der Anmeldung
- Der Username und das Passwort wird nach folgenden Regeln geprüft: …
- Sind die Daten valide, werden diese gegen das System XXX entsprechend der folgenden Spezifikation geprüft: …
- …
Darstellung der Seite nach erfolgreicher Anmeldung
- Ist die Prüfung gegen das System XXX erfolgreich, wird der User auf die Seite YYY weitergeleitet
- …
Fehleranzeige im Falle einer fehlgeschlagenen Anmeldung
- Im Fehlerfall erfolgt die Anzeige des Fehlers entsprechend des folgendem Designs: …
- …
Gültigkeit der Anmeldung
- Eine erfolgreiche Anmeldung ist für 30 Minuten nach der letzten Aktivität des Nutzers gültig.
- Ist ein User mehr als 30 Minuten nicht aktiv, wird er bei der nächsten Interaktion auf die Login-Seite zurückgeführt.
- …
Out-of-Scope
- Aktiver Logout durch den User
- Details auf der Seite nach dem Login (siehe User-Story XXX)
Umsetzungsdetails
- Beim System XXX soll das Testsystem mit folgender URL angebunden werden:
- Für die Validierung ist die ValidationRequest-Klasse zu verwenden.
Fazit
Es gibt viele Wege wie eine User-Story beschrieben werden kann und unsere Methodik ist für uns eine gute Best Practice, die sich in den letzten zehn Jahren bewährt hat.
Allerdings hat man nicht immer die Möglichkeit, ein eigenes Format für User-Stories zu wählen, manchmal wird einem sogar das Format von User-Stories in Projekten vorgegeben. In jedem Fall ist es bei einer guten User-Story enorm wichtig, der Zielgruppe der Story – meistens den Entwicklern und Testern – eine möglichst vollständige, klare und leicht verständliche Sicht auf die Anforderungen der abzudeckenden Funktion zu geben.
Nur so ist eine effiziente Umsetzung des dahinterliegenden Features möglich.
