Besonders in der agilen Softwareentwicklung ist der Begriff User Story ein immer wichtiger werdender Bestandteil. Aber was bedeutet er eigentlich und worin liegt der Nutzen? Im Folgenden möchte ich diesen Begriff auch Nicht-Entwicklern erklären und zeigen, warum der Einsatz von User Stories zeitsparend (und damit auch kosteneinsparend) sein kann.
Begriffserklärungen: User Story, Story Card und Storymap:
Bei der User Story handelt es sich um eine Anforderung an die zu entwickelnde Software, die als Wunsch in Alltagssprache übersetzt und so Entwickler und Kunden gleichermaßen verständlich gemacht wird. Eine User Story besteht in der Regel aus einem kurzen Satz, der „wer“, „was“ und „warum“ enthält und aus Sicht des Nutzers geschrieben wird.
Im Detail bedeutet das:
„Als (Anwenderrolle) möchte ich (Wunsch/Ziel beschreiben), um (welchen Nutzen habe ich dadurch?).“
Ein Beispiel:
„Als Nutzer möchte ich nach dem Login direkt zu meinem Dashboard gelangen, damit ich nicht von anderen Funktionen abgelenkt werde.“
User Stories versetzen den Kunden auch in die Lage, die Software und deren Funktionen zu testen. Im Dialog zwischen Kunde und Entwickler werden deshalb Bedingungen aus der User Story ergänzt, die erfüllt sein müssen, damit die User Story als umgesetzt/erledigt angesehen werden kann. Diese Bedingungen nennt man Akzeptanzkriterien.
Ein Beispiel dafür:
„Teste, ob ich nach dem Login automatisch zum Dashboard geführt werde.“
Die User Story wird auf eine Story-Card geschrieben. Das wird so genannt, weil die Story so kurz und knapp formuliert sein soll, dass sie auf eine Karteikarte passt. Auf der Rückseite sollten die Akzeptanzkriterien aufgeführt werden.
Wenn alle User Stories erstellt sind, werden sie übersichtlich angeordnet. Das Ergebnis ist dann die sogenannte User Story Map. Hier werden alle aufeinanderfolgenden Aktivitäten/Wünsche des Anwenders nebeneinander (jeweils mit einer eigenen User Story) gelegt. Diese sind eher grob und übergreifend beschrieben, werden aber nach unten hin durch detailliertere User Stories genauer spezifiziert.
Wozu all der Aufwand?
Die User Stories sind, wie bereits erwähnt, sowohl für Entwickler als auch für den Kunden klar verständlich. Damit wird umgangen, dass die Entwicklung von Software ins Stocken gerät, weil es Probleme in der Kommunikation gibt. Jeder Beteiligte kann die User Story verstehen und weiß sofort, um welche Art von Anforderung es sich handelt und was genau damit erreicht werden soll. Unnötiger Mehraufwand aufgrund von missverständlichen Formulierungen (der häufig zu Mehrkosten für den Kunden führt) gehört damit – sofern präzise formuliert – ebenfalls der Vergangenheit an.
User Stories lassen sich mithilfe von Ticketsystemen hervorragend anlegen und priorisieren. So kann man zusätzlich sichergehen, dass die wichtigsten Features zuerst programmiert werden. Das Ticketsystem ist somit also eine Repräsentation der User Story Map.
Übung macht den Meister
Zugegeben: wenn man anfängt, sich mit User Stories zu beschäftigen und sie zum ersten Mal schreibt, bekommt man das Gefühl, man würde mit einem Kleinkind sprechen. Ein einfacher Satz, immer dem gleichen Muster entsprechend. Aber spätestens beim dritten Mal fühlt sich genau diese detaillierte Beschreibung absolut richtig an, weil man feststellt, dass keine Nachfragen seitens des Entwicklers nötig sind, um das Geschriebene zu verstehen. Im Ergebnis geht die Softwareentwicklung zügig voran und man merkt schnell, wie effizient diese Methode ist, um Software agil entwickeln zu können.
Haben Sie Fragen oder benötigen Hilfe bei diesem Thema? Zögern Sie nicht uns zu kontaktieren. Wir helfen Ihnen gern weiter.
Ansprechpartner: Martin Stoll