„User Stories“ sind ein sehr beliebtes Format zum Schreiben von Anforderungen. Es ist zwar nicht das einzig mögliche Format und bei weitem nicht der einzig richtige Weg, um zu arbeiten, aber das Format hat viele Vorteile, die es so beliebt machen.
Legen wir direkt los!
Die Vorlage für eine User Story lautet:
Als <Rolle oder Persona> möchte ich <Ziel>, damit <Grund>.
Ein Beispiel:
„Als Call-Center-Agent einer Ticket-Vorverkaufsstelle möchte ich schnell Informationen über den anrufenden Benutzer finden, damit ich sie/ihn mit korrektem Namen ansprechen kann und über ihre/seine Bestellhistorie Bescheid weiß.“
Diese Art, Anforderungen zu schreiben, hat viele Vorteile:
- Man muss darüber nachdenken, wer die Anforderung gestellt hat. So kann sich das Entwicklungsteam in die Rolle des Benutzers versetzen, intelligente Fragen stellen und die richtigen Annahmen treffen.
- Man muss darüber nachdenken, was das eigentliche Ziel ist. Dies ermöglicht dem Entwicklungsteam, effiziente und kreative Lösungen für die Anforderungen zu finden.
- Man muss darüber nachdenken, warum etwas benötigt wird. Das hilft dabei, abzuschätzen, wie groß der Nutzen dieser Features ist. Letzten Endes kann man so auch den Return on Invest (ROI) abschätzen, den man dann zur Priorisierung des Backlogs nutzen kann.
Schauen wir uns ein paar Beispiele an
Das hört sich doch wirklich logisch und einfach an, oder? In der Praxis ist es jedoch oft recht schwierig und erfordert viel Übung und Zeit, wirklich aussagekräftige User Stories zu schreiben. Schauen wir uns gemeinsam ein paar der häufigsten Fehler beim Schreiben von User Stories an und wie man sie beseitigen kann.
Nehmen wir eine Hotelbuchungswebseite als Beispiel. Stell dir die folgende User Story vor:
„Als Benutzer möchte ich eine Liste von Hotels sehen (Tabellenansicht, Name, Adresse und Bilder), damit ich leicht die richtigen Informationen finden kann.“
Das hört sich ganz gut an und erfüllt die Vorgaben in unserer Vorlage. Das Entwicklungsteam könnte also sofort beginnen, daran zu arbeiten. Die User Story lässt jedoch einige Aspekte offen, die das Entwicklungsteam im besten Fall bei der Umsetzung erfragen muss oder die im schlimmsten Fall dazu führen, dass das Team falsche Annahmen dazu trifft:
- Sind die Hotels gemeint, die der Nutzer schon einmal gebucht hatte (mein letzter Urlaub), oder die Unterkünfte, die der Vermieter besitzt? Wer genau ist der „Benutzer“? Der Mieter oder der Vermieter? Beides sind tatsächliche Anwendungsfälle, aber da der "Wer"-Teil nicht genau beantwortet wurde, bleibt diese Frage offen. Stattdessen sollte man konkrete Rollen wie „Mieter“ oder „Vermieter“ verwenden.
- Soll die „Hotelliste“ eine Kartenansicht sein, die auch auf mobilen Geräten funktioniert (im Gegensatz zu einer Tabelle)? Kann das Team die bestehende Hotelliste, die bereits an anderer Stelle verwendet wurde, wiederverwenden? Da die Ansicht sehr detailliert spezifiziert ist („Tabellenansicht, Name, Adresse und Bilder“), würde das Entwicklungsteam diese Fragen höchstwahrscheinlich nicht stellen. Und da auch der „Warum“-Teil offen ist, sind die Chancen, die richtigen Annahmen zu treffen, recht gering. Lässt man stattdessen den „Was“-Teil eher allgemein, kann das Team selbst effiziente Lösungen finden (wie die Wiederverwendung von gewissen Elementen).
- Wie soll die Liste geordnet werden? Wird ein Suchfeld benötigt? Da der Grund für die Liste (warum?) nicht beantwortet wird, kann das Team diesbezüglich nicht die richtigen Annahmen treffen. Wenn es sich um die Hotels handelt, die ein Mieter schon einmal gemietet hat, ist vielleicht eine Sortierung nach Datum sinnvoll. Eine Suche ist nicht erforderlich, da es wohl nicht mehr als fünf Einträge geben wird. Wenn es sich um die Hotels handelt, die ein Vermieter besitzt, könnte die Liste 100 Einträge haben und eine alphabetische Sortierung sowie eine Suche könnten erforderlich sein. Daher sollte angegeben werden, aus welchem Grund die Funktion wirklich benötigt wird.
Die verbesserte User Story könnte folgendermaßen aussehen:
„Als Mieter möchte ich die Hotels finden, die ich bei früheren Urlauben gebucht habe, damit ich sie erneut buchen und die Erinnerungen mit meinen Freunden teilen kann.“
Auf diese Weise kann man auch bei anderen Beispielen vorgehen:
Beispiel 1:
Ursprüngliche User Story:
„Als Eigentümer des Systems möchte ich eine Tabelle mit allen Kunden sehen, damit ich sie alle einsehen und die Daten analysieren kann.“
Verbesserte User Story:
„Als Buchhalter möchte ich herausfinden, welche Kunden den größten Umsatz generieren, damit ich sie mit speziellem Marketingmaterial, wie z.B. speziellen Newslettern, gezielt ansprechen kann.“
Beispiel 2:
Ursprüngliche User Story:
„Als Gast möchte ich einen roten Knopf neben dem Hotel sehen, damit ich den Buchungsvorgang mit einem Klick starten kann.“
Verbesserte User Story:
„Als potentieller Gast möchte ich Fotos, Beschreibungen und Preisinformationen über passende Hotels finden, damit ich eine Entscheidung treffen kann, welches Hotel wirklich gut für meinen nächsten
"Gut geschriebene User Stories können einem leicht tage- und wochenlanges Programmieren der falschen Dinge ersparen"
Diese 3 Punkte solltest du zum Verbessern von User Stories beachten
Hier sind ein paar Punkte, die dir dabei helfen, deine User Stories auf ein Profi-Niveau zu bringen :)
- Du kannst die etwas ausgefeiltere Methode wählen und Personas schreiben, oder es simpel halten und einfach einige Rollen definieren. Achte dabei darauf, keine generischen Rollen wie „Benutzer“, „Entwickler“, „Eigentümer“ etc. zu verwenden.
- Stelle dir selbst ehrlich die Frage, warum das Feature benötigt wird. Welches Ziel möchte der Benutzer mit der Verwendung dieser Funktion erreichen? Versuche, nicht in Implementierungen (Schaltflächen, Tabellen) zu denken, sondern in Zielen.
- Halte den „Was“-Teil allgemein und gib deinem Entwicklungsteam etwas Raum für kreative Lösungen. Details der Benutzererfahrung oder der Implementierung sollten nicht angegeben werden, es sei denn, sie sind aus irgendeinem Grund wirklich wichtig für dich.
Ich hoffe, diese Tipps sind Hilfe und Motivation für dich. Es braucht etwas Übung, aber das ist es wirklich wert. Gut geschriebene User Stories können einem leicht tage- und wochenlanges Programmieren der falschen Dinge ersparen :)
