Was sind User Stories
Ein Werkzeug, das häufig im agilen Projektmanagement eingesetzt wird, sind User
Stories. Eine User Story ist eine Beschreibung einer Anforderung an ein Softwareprodukt.
Sie ist aus der Sicht eines Nutzers (hier: Spielteilnehmer) formuliert. Außerdem
wird in einer User Story immer ein Mehrwert und eine Bedeutung für den Nutzer
erwähnt, welchen dieser durch die Funktionalität hat. Diese Funktionalität wird in
das zu erstellende Produkt implementiert und erhöht somit den Wert des Produkts.
Eine User Story liefert also immer einen Mehrwert. Der Titel der User Story beschreibt
knapp die Hauptaussage der gesamten Story, welche immer das Ziel des Nutzers ist. In
den meisten Fällen wird eine User Story in der folgenden Form geschrieben:
"Als [Rolle] möchte ich [Tätigkeit], um [Nutzen]."
Im Rahmen des Softwareprojekts könnte eine User Story beispielsweise wie folgt aussehen:
"Als Nutzer dieses Systems möchte ich mich einloggen können, um ein Spiel zu
starten." Die explizite Erwähnung der [Rolle] ist wichtig, weil der Anwendungsfall von
Rolle zu Rolle variieren kann. Die [Tätigkeit] ist der Vorgang, welchen die Rolle bei
Nutzung des vom Team zu implementierenden Produkts ausführt. Der [Nutzen] dient
zur Einordnung der Wichtigkeit und hilft, eine Priorisierung der zu implementierenden
Features vorzunehmen. Außerdem hilft es dem Team zu verstehen, warum sie dieses
Feature implementieren sollen.
Mehrwert von User Stories
Da User Stories so formuliert werden sollten, dass sie jeder versteht, kann eine intensive
Zusammenarbeit mit dem Auftraggeber (hier: intensive Zusammenarbeit mit dem
gesamten Team) entstehen. Hierdurch wird die Beziehung untereinander gestärkt und
sowohl Entwickler als auch Auftraggeber verstehen die Ziele der User Stories gleicherma-
ßen. Ein weiterer Vorteil ist die Anpassbarkeit, weil sich die Wünsche des Auftraggebers
jederzeit ändern können. Aus diesem Grund implementieren die Entwickler im schlimmsten
Fall nur für eine sehr kurze Zeit etwas, was in der nächsten Iteration hinfällig ist,
da sich der Wunsch des Auftraggebers jederzeit ändern kann. Außerdem werden nur
die Stories detaillierter beschrieben, die in der Iteration erledigt werden sollen. So wird
keine Zeit für die Planung von etwas aufgewendet, das sich im Nachhinein eventuell als
obsolet herausstellt.
Der Nutzen von Akzeptanzkriterien
Da die Entwickler eventuell unterschiedliche Vorstellungen davon haben, wann eine
bestimmte User Story fertig bearbeitet ist, hat sie bestimmte Akzeptanzkriterien. Diese
bestimmen die Vollständigkeit der in der Story gewünschten Funktion. Sobald diese
Akzeptanzkriterien erfüllt sind, ist die User Story vollständig umgesetzt und liefert nur
dann den gewünschten Mehrwert für den Auftraggeber (hier: für das Team).
INVEST-Prinzip
Es gibt bestimmte Eigenschaften, die eine gute User Story ausmachen. Mit dem INVEST-
Prinzip lassen sich diese Eigenschaften beschreiben. Dabei ist das Wort INVEST ein
Akronym für die folgenden Eigenschaften einer guten User Story:
Independent Diese Eigenschaft meint, dass eine gute User Story unabhängig von
anderen ist. Sind Stories voneinander abhängig, können Probleme entstehen, die eine
Priorisierung erschweren.
Negotiable Verhandelbare User Stories bedeuten, dass während des Entwicklungsprozesses
bestimmte Akzeptanzkriterien angepasst werden können, wenn diese mit dem
Auftraggeber (hier: mit dem gesamten Team) verhandelt wurden.
Valuable Wertvolle User Stories meinen, dass sie einen bestimmten Mehrwert für
den Auftraggeber und den Nutzer darstellen.
Estimatable Eine gute User Story soll schätzbar sein, das bedeutet, dass die Story
von anderen abgegrenzt wird, sodass sie gut unterscheidbar ist.
Small Damit eine User Story gut schätzbar ist, muss sie klein sein. Außerdem können
zu große User Stories nicht in einem Sprint bearbeitet werden.
Testable Eine testbare User Story hat gut strukturierte Akzeptanzkriterien, die
getestet werden können.
Ausreichend beschriebene User Story mit dem INVEST-Prinzip
Unzureichend beschriebene User Story mit dem INVEST-Prinzip
