Was sind gute User Stories?

Projektarbeit zeichnet sich durch die Kooperation interdisziplinärer Teams aus, vor allem in agilen Projekten. Bei der Implementierung von Scrum arbeiten viele Experten zusammen, deren Arbeit sich durch eigene Fachbegriffe und Verständnisse prägt. Auch der Nutzer und der Auftraggeber des Produkts haben ihre eigene Sprache und Ansprüche. User Stories schlagen die Brücke zwischen den Parteien und bilden die Grundlage eines jeden Scrum-Projekts.

Was sind User Stories?

Bei User Stories handelt es sich um Nutzergeschichten, die die Anforderungen der Kunden an ein Produkt beinhalten. Der Product Owner beschreibt diese Anforderungen und Erklärung eines Features aus der Sicht des Kunden. Die User Story besteht aus wenigen, leicht verständlichen Sätzen, die jedoch gleichzeitig spezifisch und detailliert sind. Ziel ist es, dass Produktentwickler verstehen, was der Kunde wirklich möchte und wie er mit dem Produkt arbeitet.

Der Begriff „User Story“ kommt im Scrum Guide gar nicht vor, wird aber bei den agilen Techniken häufig verwendet. Neben den User Stories stehen im Backlog Epics und Tasks, Qualitätsanforderungen, Fehler und Verbesserungen.

Epic, User Story und Task

Beim Epic handelt es sich um eine User Story auf höchster Abstraktionsstufe. Ein Epic ist um einiges größer als eine normale User Story und kann nicht innerhalb eines Sprints abgearbeitet werden. Deshalb wird diese vom Product Owner in mehrere kleinere User Stories zerlegt.

Eine User Story ist ein Teil vom Epic. Diese enthält die Anforderungen in Form von einem kleinen, handhabbaren Text. Auf Basis einer User Story schätzt das Team den Aufwand der Realisierung der Anforderung ein.

Eine User Story wird von den Team-Mitgliedern dann in einzelne Aufgaben, die sogenannten Tasks, zerlegt. Sobald eine Aufgabe nicht in der vereinbarten Zeit erledigt wird, können weitere zusätzliche Tasks angelegt werden. Jede User Story ist erst dann als erledigt anzusehen, wenn alle Aufgaben aus der User Story erledigt sind.

Aufbau einer guten User Story

Eine gute User Story beschränkt sich auf kurze Sätze und einfache Worte. Fachbegriffe und ausschweifende Erklärungen sind an dieser Stelle fehl am Platz. Es muss sichergestellt werden, dass alle beteiligten Kollegen sie ohne (technischen) Hintergrund verstehen. Außerdem transportieren sie Anforderungen an zukünftige Produkte oder Systeme, ohne technische Lösungen anzustoßen.

 

Der klassische Aufbau einer User Story besteht aus den Fragen Wer? Was? Warum?, die aus Sicht eines Nutzers die Wünsche an ein Produkt adressieren. Eine alternative Struktur ist das Ausfüllen des folgenden Satzes:

 

Als <Rolle> will ich <Aktion>, um <Ergebnis> zu erzielen.

 

Wer fordert was an? (Rolle)

Der Anforderer ist meistens der spätere Kunde des Produktes.

 

Was wünscht sich der Anforderer? (Aktion)

Der Anforderer möchte, dass das Produkt etwas Bestimmtes kann oder es soll etwas passieren. Je präziser dies beschrieben wird, desto klarer ist dann die User Story für das Entwickler-Team.

 

Warum ist das wichtig? (Ergebnis)

Die Anforderung soll ein Ziel haben, welches es zu erreichen gilt. Die Beschreibung des Grundes für die Anforderung liefert dann dem Entwickler-Team weitere wichtige Informationen, die zu gezielten Ergebnissen führen.

Ein weiterer verbreiteter Tipp ist das Schreiben der User Story auf Karteikarten. Dies führt dazu, dass sie präzise und knappgehalten wird und die Karten für alle gut sichtbar sind. Man kann mit ihnen weiterarbeiten und sie strukturieren.

Gute User Stories schreiben

Woran erkennt man eigentlich, dass eine User Story die richtige Größe hat? Wann ist also eine User Story richtig geschrieben? Hilfe dazu bietet die INVEST-Checkliste.

 

Independent (unabhängig)

Jede User Story soll möglichst unabhängig sein. Das bedeutet im besten Fall keine vorgelagerten User Stories haben, die Arbeit an der User Story nicht ermöglichen. Im Umkehrschluss kann es sein, dass erst mehrere vorherige, vielleicht sogar unwichtige, Stories abgeschlossen werden müssen, bevor man an die eigentliche Story ran kann.

 

Negotiable (verhandelbar)

User Stories sollen bei Bedarf auch diskutiert werden, um somit die finale Version der User Story erstellen zu können. Es geht ja schließlich darum, das Beste und Wertvollste für den Kunden zu schaffen. Daher ist es wichtig, über die Inhalte der User Stories diskutieren zu können, weil ohne Diskussionen mit anderen Team-Mitgliedern genau dieser Mehrwert für den Kunden entfallen könnte.

 

Valuable (nützlich)

Bei der Umsetzung jeder User Story sollte immer der Mehrwert angestrebt werden, sonst sollte man hier keine Zeit, Energie und Kosten dafür bereitstellen. Dabei ist zu beachten, dass es nicht immer nur um den Mehrwert für den Kunden gehen soll. Der Mehrwert kann sich ebenfalls auf eine Rolle beziehen, die in der User Story beschrieben wird. Mit diesem Fokus ist es dann später einfacher, die User Stories zu priorisieren, und dem Kunden indirekt einen Mehrwert anzubieten, indem für mehr Stabilität des Systems gesorgt wird.

 

Estimable (schätzbar)

Der Aufwand, der hinter einer jeden User Story steckt, muss für das Team schätzbar sein. Sonst sollte man die Beschreibung der User Story nochmal überarbeiten.

 

Small (klein)

Jede User Story muss eine überschaubare Größe haben. Grund dafür ist, dass bei größeren Aufgaben das generelle Risiko steigt. Weiteres Problem mit den großen Aufgaben ist es, dass diese dann sehr schwer einzuschätzen sind.

 

Testable (testbar)

Eine User Story kann erst dann als erledigt („done„) bezeichnet werden, sobald diese vom Product Owner abgenommen wird. Der Product Owner muss das definierte Ziel überprüfen können. Aus diesem Grund sollte beim Verfassen einer jeden User Story gut überlegt werden, woran man diese Zielerreichung erkennen kann und genaue Akzeptanzkriterien formulieren.

Haben Sie Fragen?

Palina Vorobeva

Beitrag teilen:

Weitere interessante Beiträge

Scroll to Top
Scroll to Top