Ihr konntet in einem früheren Blogpost bereits erfahren, wie ich User Story Mapping in der Releaseplanung anwende. In diesem Beitrag möchte ich jedoch zurück an den Anfang. Oder zumindest so weit zurück, dass ich euch erklären kann, was meiner Meinung nach eine gute User Story ausmacht. Doch beginnen wir ganz vorne: Was ist eine User Story überhaupt?
User Story – Die Anwendererzählung
Eine User Story ist laut Definition eine in Alltagssprache formulierte (Software-)Anforderung. Sie kann ein Nutzerbedürfnis repräsentieren, als Planning Item in der agilen Softwareentwicklung dienen oder auch einfach als Gesprächsgrundlage genutzt werden. User Stories sind für jeden verständlich und drücken den Kundennutzen klar aus.
User Stories sind nicht zu verwechseln mit Use Cases. Letztere kommen aus der klassischen Softwareentwicklung und stellen ebenfalls Anforderungen in natürlicher Sprache und im Kontext der Nutzer dar. Der Unterschied ist jedoch, dass Use Cases alle Erfolgs- und Misserfolgsszenarien des formulierten fachlichen Problems darstellen. Das Use Case bildet somit den gesamten Rahmen und beinhaltet mehrere Szenarien, die zu einer bestimmten fachlichen Anforderung passen. Eine User Story hingegen beschreibt ein ganz konkretes Szenario.
Doch wie ist eine User Story überhaupt aufgebaut und worauf sollte man bei ihrer Erstellung achten?
User Stories werden prinzipiell aus der Sicht des Nutzer geschrieben und erfassen das "Wer", "Was" und "Warum" einer Anforderung. Eine Story braucht zunächst einen Titel (z.B. "Abweichende Lieferadresse"), der prägnant zusammenfasst, worum es geht. Anschließend sollte eine Beschreibung hinzugefügt werden. Hierbei kann man sich an folgender Vorlage orientieren:
"Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>."
Ein Beispiel wäre: Als Kunde eines Online-Shops möchte ich eine abweichende Lieferadresse angeben können, um ein Geschenk an eine beliebige Person zu verschicken.
Nach der Beschreibung können weitere Informationen ergänzt werden, wie z.B. Akzeptanzkriterien, Spezifikationen und Wireframes. Akzeptanzkriterien sind besonders wichtig, denn sie signalisieren den Entwicklern, wann die User Story erledigt ist und welche Schritte dazu notwendig sind. Eine User Story sollte kurz und prägnant sein, sodass ihr Inhalt auf eine Karteikarte passen würde.
Eine fertig geschriebene User Stories wird anschließend im Product Backlog eingebunden und dort priorisiert.
INVEST: 6 Kriterien für gute User Stories
Bei INVEST handelt es sich um ein Akronym, welches ursprünglich von Bill Wake für agile Softwareprojekte entwickelt wurde. Es dient als Gedankenstütze, um die Elemente eines Product Backlogs mit entsprechend hoher Qualität aufbauen zu können. User Stories sind dabei eine weitverbreitete Methode, um diese Product-Backlog-Elemente zu entwickeln.
Im besten Fall sollte jede User Story nach dem INVEST-Prinzip geschrieben werden:
| I (Independent) | Sie ist nicht von einer anderen User Story abhängig. |
| N (Negotiable) | Sie dient als Gesprächsgrundlage und kann gemeinsam weiterentwickelt werden. |
| V (Valuable) | Sie stellt immer einen Vorteil für den User, Kunden oder Auftraggeber dar. |
| E (Estimatable) | Sie ist schätzbar. Sie hat also so viel konkrete Details, dass ein erfahrenes Team deren Umfang schätzen kann. |
| S (Small) | Sie hat die richtige Größe. |
| T (Testable) | Sie beinhaltet genügend Informationen, um getestet werden zu können. |
Was macht eine gute Story noch aus?
Neben der INVEST-Eselsbrücke sind mir in meinen bisherigen Projekten noch weitere Tipps zur Erstellung einer guten User Story begegnet:
- Behaltet den Nutzer stets im Fokus.
- User Stories werden nicht von einer Person alleine erstellt – Teamarbeit ist gefragt und Kommunikation besonders wichtig.
- Akzeptanzkriterien erleichtern die Arbeit.
- Weniger ist manchmal mehr – User Stories sollten kurz und präzise formuliert werden.
- Macht die Stories sichtbar, sodass jeder sie einsehen kann und präsent hat.
- User Stories sind kein Allheilmittel – nicht immer macht es Sinn eine User Story zu schreiben, fühlt euch nicht verpflichtet dazu.
Abschließend kann man einige abschließende Fragen stellen, um sich sicher zu sein, ob eine User Story wirklich gut ist. Hilfreich dabei sind Fragen wie:
- Welches Problem wird in der Story adressiert?
- Wessen Problem wird durch diese Story gelöst?
- Wurde das Problem verstanden und genügend hinterfragt?
- Wurde das Problem lediglich als Anforderung vom Kunden übernommen? Wenn ja, gibt es andere Lösungen für dieses Problem?
Übung macht den (User-Story-)Meister
All diese kleinen Tipps und Tricks haben mir in meinen bisherigen Projekten geholfen, gute User Stories zu schreiben, mit denen das gesamte Team arbeiten konnte und auch der Kunde die Anforderungen und Problemlösungen präsent hatte. Dennoch schreiben sich gute User Stories nicht von alleine – es braucht viel Übung.
In meinem nächsten Blogbeitrag möchte ich euch gerne etwas zum Thema “User Stories richtig schneiden” erzählen. Es ist nicht immer einfach, die richtige Größe einer Story zu finden, doch auch hier gibt es Techniken, die euch die Arbeit erleichtern.
Probiert das Schreiben von User Stories und ihren Einsatz im Release Planning doch bis dahin einfach mal aus und ladet euch unser passendes Template kostenlos herunter.
Kommentare