Gute User Stories schreiben (inkl. INVEST-Checkliste)

User Stories sind ein zentrales und extrem hilfreiches Element in der täglichen Arbeit von SCRUM-Teams! Aber wusstest du, dass der Begriff „User Story“ im Scrum Guide kein einziges Mal auftaucht? Statt von User Stories wird nämlich nur von Backlog Einträgen gesprochen.

Aber auch wenn User Stories keine „Pflicht“ für SCRUM-Teams sind, werden sie wohl doch in fast allen SCRUM-Teams eingesetzt.

Obwohl die Grundidee von User Stories eigentlich sehr einfach ist, stellen sich bei der Arbeit mit ihnen viele Fragen. Und leider schaffen es nur sehr wenige Teams, die Vorteile von gut formulierten User Stories wirklich nutzen zu können.

Im Folgenden erfährst du, wie du herausragende User Stories schreiben kannst. So reduzierst du Missverständnisse in deinem Team und steigerst die Produktivität deines Projekts enorm.

Was ist eine User Story?

Projekte sind geprägt von der Arbeit in interdisziplinären Teams. Gerade in agilen Projekten, die mit SCRUM umgesetzt werden, arbeiten viele Spezialisten mit- bzw. nebeneinander. Aber jeder dieser Spezialisten – egal ob Entwickler, Designer, Vertriebler, etc. – spricht seine ganz eigene Sprache. Und so ist es auch nicht verwunderlich, dass immer wieder Missverständnisse auftreten.

Diese babylonische Sprachverwirrung sollen User Stories bekämpfen oder sogar verhindern. Bei User Stories handelt es sich um eine kurze Beschreibung einer gewünschten Funktion aus Sicht des betroffenen Anwenders. Die Beschreibung folgt meist einem einfachen Schema:

Wie du siehst, wird hier aus der Sicht eines Nutzers ein Wunsch und der dahinter liegender Nutzen beschrieben.

Beispiel einer User Story

Um dieses Prinzip greifbar zu machen, hier ein mögliches Beispiel für ein Online-Portal eines Mobilfunkanbieters:

Das optimierte User Story Template (Profi Tipp)

Soweit so gut. Was mir immer wieder auffällt, ist dass in vielen User Stories die ersten beiden Elemente – d.h. die Frage nach der Rolle und dem Ziel/Wunsch – meist noch ausreichend berücksichtigt werden.

Leider wird dann aber auf die letzte Frage – nach dem Nutzen – oft nicht mehr so viel Wert gelegt. So wird in der Folge viel Mehrwert verschenkt! Denn in der Frage nach dem WARUM stecken viele Informationen, die letztlich den Unterschied zwischen einer guten und einer sehr guten Lösung ausmachen.

Würden wir uns in unserem Beispiel nämlich nur darauf konzentrieren, dass der Kunde seinen Datenverbrauch sehen will, könnte die Lösung wie folgt aussehen:

Diese Information ist aber letztlich nur eine Zwischenziel. Was der Kunde eigentlichen wissen will ist, ob er für den verbleibenden Abrechnungszeitraum noch ausreichend Datenvolumen zur Verfügung hat.

Eine kundenorientierte Lösung könnte deshalb wie folgt aussehen:

Ihr aktueller Datenverbrauch:

Um aber genau diesen Fokus auf den Nutzen nicht zu verlieren, empfehle ich dir das oben beschriebene Muster wie folgt umzustellen:

Mit diesem kleinen Trick wird der Nutzen noch mehr in den Fokus gerückt und das kann bei der Lösungsfindung Wunder wirken.

Wie schreibt man eine gute User Story?

Nachdem du jetzt das optimierte User Story Template – mit dem Fokus auf den Nutzen – kennst, bist du schon gut gerüstet. Aber woran erkennst du eigentlich, dass deine User Story die richtige Größe hat? Wann ist sie also „richtig geschnitten“? Hilfreich ist hierbei die INVEST-Checkliste.

Jede gute User Story sollte eine Reihe von Kriterien erfüllen. Das INVEST-Akronym hilft dir dabei:

Independent (unabhängig)
Jede User-Story sollte möglichst unabhängig sein, d.h. es sollte wenig bis keine vorgelagerten Stories geben, die die Entwicklung dieser Story blockieren. Denn sonst kann es sein, dass du erst mehrere unwichtige (= wenig wertvolle) Stories bearbeiten musst, bevor du die eigentlich wichtige Story umsetzen kannst.

Negotiable (verhandelbar)
An User Stories sollen sich immer Diskussionen entfachen (können) und die finale Version der Story sollte dann immer das Ergebnis dieser Gespräche sein. Denn letztlich geht es darum, das Beste für den Nutzer herauszuholen. Und was das ist kann selten von einer Person – ohne Diskussionen mit anderen Beteiligten – bestimmt werden.

Valuable (nützlich)
Die Umsetzung einer User Story sollte immer zu einem Mehrwert führen. Ansonsten sollte für sie keine Zeit/Energie/Kosten aufgewendet werden. Dabei ist es mir aber wichtig anzumerken, dass es nicht immer nur um den Mehrwert des Kunden gehen muss. Der Mehrwert bezieht sich vielmehr auf die Person/Rolle, die in der Story beschrieben wird. Mit einem solchen Fokus auf den Mehrwert ist es viel einfacher auch Stories zu priorisieren, die zwar dem Kunden keinen direkten Mehrwert bieten, aber für die Stabilität des Systems nötig sind. Und wenn solche Stories – aufgrund des “fehlenden” Kunden-Mehrwerts – zu wenig Beachtung finden, dann wird schnell auch der Kunde leiden.

Estimable (schätzbar)
Der Aufwand für eine User Story muss einschätzbar sein (siehe hierzu auch mein Artikel zum Planning Poker).

Small (klein)
Eine User Story sollte eine überschaubare Größe haben. Wichtig ist dies u.a. deshalb, weil bei größeren Aufgaben auch das generelle Risiko steigt. Und je größer eine Aufgabe ist, desto unpräziser wird die Schätzung auch sein. Deshalb sind die Karten beim Planning Poker auch nach der Fibonacci Reihe nummeriert.

Testable (testbar)
Bevor eine User Story als “fertig” bezeichnet werden kann, muss sie natürlich (vom ProductOwner) “abgenommen” werden. Es muss also überprüft werden, ob das gewünschte Ziel erreicht wurde. Deshalb solltest du dir auch immer schon beim Schreiben der User Story überlegen, woran man diese Zielerreichung eigentlich erkennen kann.

INVESTiere in gute User Stories

Wie du siehst können User Stories extrem hilfreich bei der täglichen Arbeit von SCRUM-Teams sein. Hierfür reicht es aber leider nicht aus, einfach nur schnell das Template:

auszufüllen.

Um richtig gute und hilfreiche User Stories zu schreiben, bedarf es vielmehr. Und der kleinste Teil dieser Arbeit dreht sich um das eigentliche Schreiben der User Story. Viel wichtiger sind die Gesprächen mit verschiedenen Beteiligten/Experten, um ein klares und einheitliches Verständnis darüber zu bekommen: WER (Rolle), WAS will (Ziel/Wunsch) und vor allem WARUM (Mehrwert).

Und wenn du dann beim Schreiben deiner User Stories auch noch die INVEST-Kriterien anlegst, dann bist du deinem Ziel schon sehr nahe gekommen