Was sind User Stories?

Bei allen agilen Frameworks und Methoden geht es darum, iterativ und inkrementell zu arbeiten. Ein weiteres Merkmal ist außerdem die konsequente Ausrichtung auf den Kunden und seine Bedürfnisse, um den maximalen Kundennutzen zu erzielen. Der Kunde wird in das Zentrum aller Aktivitäten gestellt. Bei allem was man tut, geht es letztendlich darum, welchen Wert dies für den Kunden schafft. Eine User Story ist eine kurze, einfache Beschreibung einer Anforderung aus Kundensicht. Das User Story Format erfreut sich insbesondere im Zusammenhang mit agilen Frameworks und Methoden großer Beliebtheit. Das User Story Format ist aber nicht Teil eines agilen Frameworks und daher auch auf kein einzelnes Framework beschränkt. Entgegen der häufig anzutreffenden Meinung hat das User Story Format auch nichts mit dem Scrum Framework zu tun.

Formulierung und Akzeptanzkriterien

Formulierung

Die Formulierung einer User Story ist eine kurze, einfache Beschreibung einer Anforderung aus Kundensicht. Sie besteht oft nur aus einem einzigen Satz, der ein bestimmtes Format hat:

Als Rolle möchte ich Ziel, um Nutzen.

Das Element “Rolle” beschreibt, wer genau diese Anforderung benötigt. Man sollte versuchen, hier so spezifisch wie möglich zu sein und allgemeine Begriffe wie “Anwender”, “Kunde” oder “Nutzer” möglichst zu vermeiden. Besser sind stattdessen genauere Eingrenzungen des Kunden oder Nutzers, der diese Anforderung hat. Umso konkreter das Bild ist, das man von dem Kunden oder Nutzer hat, umso besser und passender wird die Umsetzung der Anforderung am Ende sein. Die Elemente “Ziel” und “Nutzen” klingen zunächst recht ähnlich, haben aber eine klare Unterscheidung. Das “Ziel” beschreibt die Absicht, die der Kunde oder Nutzer verfolgt, und was er damit erreichen möchte. Der “Nutzen” beschreibt wiederum den Wert, den das Erreichen des Ziels für den Kunden oder Nutzer hat.

Da die Formulierung einer User Story sehr kurz gehalten ist und oft nur aus einem Satz besteht, ist es umso wichtiger, dass die drei Bestandteile “Rolle, “Ziel” und “Nutzen” so konkret wie möglich formuliert sind. Eine User Story ist keine Spezifikation, die alle Details beschreibt. Stattdessen soll sie dem Team, das sie umsetzt, Raum für Kreativität lassen, damit das Team die bestmögliche Lösung finden kann. Je komplexer ein Umfeld ist, umso unwahrscheinlicher ist es, dass man bei der Formulierung einer Anforderung bereits definieren kann, wie die bestmögliche Lösung aussieht. Stattdessen soll die User Story einem Team nur die Richtung weisen, das Team aber den besten Weg finden lassen. Es ist daher von enormer Bedeutung, dass ein Team den Charakter einer Anforderung versteht und weiß, was der Sinn dahinter ist.

Akzeptanzkriterien

Während die Formulierung einer User Story bewusst Raum für eine kreative Lösung lassen soll, grenzen Akzeptanzkriterien diesen Lösungsraum ein. Eine User Story sollte ca. 3-5 Akzeptanzkriterien besitzen. Hat eine User Story weniger Akzeptanzkriterien, besteht die Gefahr, dass die Lösung zu offen ist und eventuell den Vorstellungen nicht entspricht. Hat eine User Story zu viele Akzeptanzkriterien, wird die Kreativität des Teams eventuell unnötig stark eingeschränkt.

Als Faustformel kann man sich merken, dass eine User Story erledigt sein sollte sobald ihre Akzeptanzkriterien alle erfüllt sind. Wenn alle Akzeptanzkriterien erfüllt sind, die Umsetzung der User Story aber dennoch nicht zufriedenstellend ist, waren entweder zu wenige Akzeptanzkriterien vorhanden oder die Akzeptanzkriterien waren nicht klar genug formuliert.

Die Akzeptanzkriterien einer User Story sollten eindeutig und klar messbar sein. Akzeptanzkriterien sollten keinen Spielraum besitzen oder unterschiedlich interpretiert werden können. Für Akzeptanzkriterien hat sich folgendes Format bewährt:

Akzeptiert, wenn Bedingung

Das Geheimnis einer guten User Story liegt in dem Zusammenspiel der Formulierung mit den Akzeptanzkriterien. Die Formulierung der User Story gibt nur eine Richtung bzw. einen Weg vor (“Fahre von München nach Mailand."). Die Akzeptanzkriterien eliminieren unzulässige Optionen (“Nimm das Auto und gebe nicht mehr als 100,- Euro aus."). Innerhalb der Akzeptanzkriterien kann die Aufgabe vom Team aber frei gelöst werden. Bei einer guten User Story kommt es oft vor, dass der Anforderer von der Kreativität des Teams überrrascht wird, da dieses auf eine Lösung gekommen ist, die er so nicht erwartet hätte.

User Story

Vorteile von User Stories

User Stories haben eine ganze Reihe von Vorteilen gegenüber klassischen Anforderungen oder Spezifikationen. Bei klassischen Anforderungen werden oft nur Aufgaben abgehakt. User Stories fokussieren dagegen auf den Kunden oder Nutzer und den Wert, der für diesen geschaffen wird. Dadurch, dass User Stories die Lösung nicht vorgeben, fördern sie die Kommunikation und Zusammenarbeit im Team. Das Team wird gezwungen, sich mit den Anforderungen auseinanderzusetzen und zu überlegen, wie mögliche Lösungen aussehen könnten. User Stories inspirieren ein Team, fördern die Kreativität und führen oftmals zu besseren Lösungen, als wenn diese bereits vorgegeben wären. Dadurch, dass User Stories vollständige Anforderungen aus Kundensicht beschreiben, können sie nach der Umsetzung den Kunden oder Nutzer direkt zur Verfügung gestellt werden. Das Team sieht so direkt den Erfolg seiner Arbeit und bekommt umgehendes Feedback der Kunden oder Nutzer.

INVEST

Neben den bereits vorgestellten Anforderungen an die Formulierung und Akzeptanzkriterien einer User Story gibt es eine Reihe Kriterien, mit denen die Qualität einer User Story bewertet werden kann. Dieses Set an Kriterien wird unter dem Namen INVEST zusammengefasst. INVEST ist ein Akronym und steht für Independent, Negotiable, Valuable, Estimable, Small und Testable.

Independent

User Stories sollten unabhängig voneinander sein und keine Abhängigkeiten untereinander besitzen. Dies ist wichtig, damit sie in einer beliebigen Reihenfolge umgesetzt werden können. Die Auswahl der als nächstes umzusetzenden User Stories sollte immer nur danach erfolgen, was aktuell den höchsten Wert für den Kunden oder Nutzer liefert. Gibt es Abhängigkeiten zwischen User Stories, müssen eventuell User Stories vorgezogen werden, weil sie für die Umsetzung anderer User Stories notwendig sind, auch wenn sie selber aktuell nicht den höchsten Wert für den Kunden oder Nutzer liefern.

Negotiable

User Stories sollen verhandelbar sein. Damit ist gemeint, dass sie, im Gegensatz zu Spezifikationen, keine Lösung vorgeben sollen. Stattdessen sollen sie in eine Richtung weisen, zu einem Austausch einladen und Raum für Kreativität lassen. Sie sollten aber kein unverhandelbarer Vertrag sein.

Valuable

User Stories sollen einen Wert für den Kunden oder Nutzer haben, aus dessen Perspektive sie geschrieben sind. Dies hilft auch dabei, eine Reihenfolge für die User Stories festzulegen und zuerst an den User Stories zu arbeiten, die den höchsten Wert für den Kunden oder Nutzer liefern.

Estimable

Die Komplexität einer User Story sollte abschätzbar sein. Je komplexer eine User Story ist, desto höher ist in der Regel auch der Aufwand für ihre Umsetzung. Dass die Komplexität einer User Story geschätzt werden kann, ist wichtig, da eine User Story, die zwar einen etwas höheren Wert, aber eine deutliche höhere Komplexität als eine andere User Story besitzt, eventuell trotzdem nach dieser umgesetzt werden soll. Auch wenn der Wert für den Kunden theoretisch höher wäre, kann die Berücksichtigung des Aufwands zu einer Anpassung der Reihenfolge führen.

Small

Wenn man agile Frameworks einsetzt, arbeitet man in kurzen Iterationen, um laufend Wert für den Kunden oder Nutzer zu schaffen. Es ist wichtig, dass User Stories innerhalb einer Iteration umsetzbar sind. Wenn User Stories zu komplex für die Umsetzung innerhalb einer Iteration sind, müssen sie geschnitten und in kleinere User Stories aufgeteilt werden.

Testable

User Stories müssen objektiv messbare Akzeptanzkriterien haben und testbar sein. Wenn in kurzen Iterationen gearbeitet wird und laufend neue User Stories umgesetzt und ausgeliefert werden, ist es wichtig, dass die Funktionalität der vorhandenen User Stories zu jeder Zeit sichergestellt werden kann.

INVEST

Epics und Themes

Epics

Wenn eine Anforderung so groß ist, dass diese nicht mehr innerhalb einer Iteration umgesetzt werden kann, muss sie in mehrere User Stories aufgeteilt werden. Ein Epic fasst diese zusammengehörenden User Stories zusammen. Ein Epic ist also nichts anderes als eine sehr große Anforderung, die über mehrere kleinere User Stories umgesetzt wird. Auch wenn User Stories zu einem Epic gehören, sollten Sie in sich abgeschlossen und potentiell auslieferfähig sein. Ein Epic wird nicht direkt von einem Team umgesetzt, sondern ein Team arbeitet immer nur an User Stories. Ein Epic kann einem Team aber die Orientierung erleichtern, da es zusammengehörige User Stories gruppiert.

Themes

Während User Stories in einem Epic zu einer gemeinsamen, sehr großen Anforderung gehören, bieten Themes eine andere Perspektive. Ein Theme erlaubt es einem, User Stories, die zu unterschiedlichen Anforderungen gehören, thematisch zusammenzufassen. Man kann damit auf einen Blick erkennen, welche User Stories einen bestimmten Teil eines Produkts oder einer Applikation betreffen, unabhängig davon, zu welcher Anforderung sie gehören. Man kann sich Epics als vertikale Gruppierung vorstellen, während Themes eine horizontale Gruppierung quer über verschiedene vertikale Gruppen hinweg bilden.

Ebenfalls für Sie interessant?

Agile Team CoachingScrum Simulation Seminar
Unsere Agile Coaches helfen dabei, agile Teams aufzubauen oder bereits bestehende agile Teams zu High-Performance-Teams weiterzuentwickeln.Wie können wir die Vorteile von agilem Arbeiten mit Scrum praktisch erleben? Wie erreichen wir ein gemeinsames Verständnis für agiles Arbeiten im Team?
Zum CoachingZum Seminar