Eine gute User Story zu schreiben, ist nicht kompliziert. Aber enorm wichtig, damit ein Scrum-Team perfekt liefern kann.
Zwischen Anwendern und Entwicklern gibt es häufig eine Kluft: Die einen haben eine Vorstellung davon, was sie benötigen, können es aber oft nicht beschreiben. Die anderen können zwar fast alles entwickeln, haben aber nur eine vage Vorstellung davon, was es leisten soll und warum.
User Stories sind die Brücke: sie beschreiben Anforderungen und Funktionen einer IT-Anwendung aus Sicht des Anwenders, damit die Entwickler die gewünschte Funktion verstehen und realisieren können. Die Aufgabe des Product Owners ist es, diese Anforderungsermittlung zu managen.
Eine gute User Story beschreibt für alle Seiten nachvollziehbar ein konkretes Nutzungsszenario. Zum Beispiel:
Als Kunde des Shops möchte ich mich am Ende des Einkaufs registrieren können, um meine E-Mail-, Adress- und Bankdaten für zukünftige Einkäufe zu nutzen.
In diesem Szenario finden sich die drei wesentlichen Elemente, die eine gute User Story ausmachen:
- welche Person (bzw. Rolle) handelt
- welche Funktion der Anwendung benötigt sie
- welches Ziel (welchen Nutzen) möchte sie erreichen
Abstrakt gekürzt lautet eine User Story also:
Als [Rolle] möchte ich [Funktion] um [Ziel/Nutzen] zu erreichen.
Die Rolle = wer?
Es ist wichtig festzulegen, welche Rolle die Person hat, die die Funktion ausführt. Denn statt „Kunde des Shops“ könnte dort beispielsweise auch „Partnershop-Betreiber“, „Verkäufer“ oder „Mitarbeiter im Versand“ stehen. Diese Personen greifen auch auf die Shop-Anwendung zu, haben aber ganz andere Anforderungen.
Die Funktion = was?
Die Funktion beschreibt das Szenario und was genau passieren soll. Dies sollte möglichst klar und präzise formuliert sein. Hier sollten aber keine technischen Lösungsvorschläge stehen. Über das „wie“ entscheiden die Entwickler. Die Funktion beschreibt, was passiert – nicht, wie es passieren soll.
Der Nutzen / das Ziel = warum?
Der Nutzen beschreibt, was sich der Person von der Funktion verspricht, also was der Mehrwert ist. Die Beschreibung des Nutzens liefert den Entwicklern wichtige Zusatzinformationen und sollte möglichst konkret beschrieben werden. Im Beispiel oben ergibt sich der Nutzen der Funktion “Registrierung” also nicht einfach nur durch das Speichern eines Logins inklusive Passwort, sondern erst durch das Speichern von E-Mail-, Adress- und Bankdaten.
Erst über die Ausformulierung des Nutzens wird klar, warum der Kunde sich eine bestimmte Funktion wünscht. Es hilft aber, auch den Nutzen zu hinterfragen, denn manchmal versteckt sich dahinter noch ein ganz anderer wichtiger Wunsch.
Beispiele für gute und schlechte User Stories
In unserem Entwicklungsalltag achten wir darauf, dass User Stories die drei wesentlichen Kernelemente enthalten. Betrachten wir also einmal Beispiele, die nicht ideal sind. Etwa die extrem kurze Aufgabe:
„Implementierung eines Reports“
Hier fehlen die Rolle und der Nutzen. Wer möchte den Report sehen und was möchte er erreichen? Davon hängt dann vermutlich ab, welche Daten der Nutzer benötigt.
„Als Redaktionsleiter möchte ich eine einfache Suche.“
Hier sind Rolle und Funktion genannt, aber der Nutzen fehlt. Was möchte der Redaktionsleiter denn suchen? Nach Artikeln oder nach Redakteuren und deren heutigen Aufgaben?
„Für die monatliche Auswertung der Buchungen sollen Daten per Web-Scraping aus dem Webportal XY erfasst und übersichtlich aufbereitet werden.“
Auch diese User Story hat viele Probleme. Für wen (= Rolle) soll die Funktion sein? Sie gibt das „wie“ vor (Web-Scraping), ohne zu wissen, ob es eventuell noch andere, technisch bessere Möglichkeiten gibt (das sollten die Entwickler entscheiden). „Übersichtlich aufbereitet“ sieht zwar nach einem Nutzen oder Ziel aus, ist aber sehr schwammig formuliert und wenig konkret. Besser wäre für den obigen Fall eine User Story wie
„Als Carsharing-Kunde möchte ich jederzeit eine Übersicht über gefahrenen Strecken und CO₂-Werte, um abzuschätzen, wie groß mein ökologischer Fußabdruck ist.“
Hier sind alle Elemente vorhanden: Rolle, Funktion und Nutzen sind klar ausformuliert, ohne technische Vorgaben zu machen, wie das geschehen soll.
Fazit
Eine gute User Story zu schreiben, ist nicht schwer, wenn man sich mit „wer“, „was“ und „warum“ das Nutzungsszenario vor Augen führt und präzise ausformuliert.
In einem späteren Blogbeitrag werden wir das Thema „User Stories“ noch einmal aufnehmen, um über die INVEST-Kriterien von Bill Wake eine weitere Qualitätsbeurteilung guter User Stories vorzunehmen.
Sie suchen nach einem kompetenten Entwicklungspartner mit viel Erfahrung in Scrum und Agiler Software-Entwicklung? Wir unterstützen Sie gerne mit Workshops und Beratungsleistungen bei der Vorbereitung, der Anforderungsanalyse und Zieldefinition sowie der Entwicklung und Umsetzung. Nehmen Sie gerne Kontakt über unsere Webseite, per Telefon +49 621 66 988 988 oder E-Mail auf.
