User Story

User Stories sind eine Technik zur Beschreibung von Anforderungen aus der Perspektive eines Benutzers unter Verwendungen von Alltagssprache. In Scrum werden User Stories als Product Backlog Einträge verwendet. Sie werden vom Product Owner:in geschrieben.

Eine User Story beschreibt, was der Benutzer erreichen will und warum er oder sie es will.

 

User Stories folgen im Allgemeinen diesem Muster:

• "Als BENUTZER will ich ZIEL/WUNSCH, damit NUTZEN."

Eine User Story sollte kurz und präzise sein und auf eine kleine Karteikarte passen.

 

User Stories sind ein einfacher und leichter Weg, mit Anforderungen von Kunden umzugehen. Dabei kann es sich um Produkt- oder Dienstleistungsanforderungen handeln. Das Ziel von User Stories ist, die Anforderungen leicht zu verstehen und sie schrittweise zu verfeinern und aufzuschlüsseln.

 

Schreiben von User Stories

Um User Stories zu schreiben, setzen sich der Product Owner:in und das Entwickler:innen (oder nur einer davon) mit dem Kunden zusammen. Der Kunde formuliert die User Stories. Das Entwickler:innen kann den Kunden durch Fragen dabei unterstützen, z.B. ob bestimmte Funktionalitäten gewünscht werden, sollte aber aufpassen den Prozess des Formulierens nicht zu sehr zu dominieren.

User Stories sind nach dem initialen Aufschreiben nicht unbedingt endgültig. Wenn das Entwickler:innen oder der Kunde sie in irgend einer Weise als unzureichend erachtet (zu groß, zu kompliziert oder zu unpräzise), können sie verfeinert oder geteilt werden.

 

User Stories können mit Akzeptanzkriterien kombiniert werden. In diesem Fall schreibt der Kunde die Kriterien auf, anhand derer er beurteilt, ob die Lösung für die User Story angemessen ist. Sie werden an die User Story angehängt.

CCC - Card, Conversation, Confirmation

Card - Karte	Eine User Story muss auf eine Karte passen.
Conversation - Dialog	Eine User Story ist die Grundlage für den Dialog der Beteiligten.
Confirmation - Bestätigung	Die Bestätigung durch den Akzeptanztest ermöglicht den einfachen Ansatz mit Card / Karte und Conversation / Dialog darüber.

Card - Karte

User Stories werden auf Karten geschrieben. Die Karte enthält nicht die gesamte Information der Anforderung, sondern gerade genug Text, um die Anforderung eindeutig zu identifizieren und dient als Erinnerungsanker für die zugrundeliegende User Story. Die Karte dient quasi als Symbol für die Anforderung und wird während der Planung genutzt. Auf der Karte können Notizen zu Priorität und Kosten gemacht werden. Sie wird meist den Programmierern übergeben, sobald die User Story für die Implementierung eingeplant wird und von diesen an den Kunden zurückgegeben, wenn die User Story erledigt ist.

Conversation - Dialog

Die Anforderung wird den Programmierern vom Kunden in einem Dialog vermittelt: Es findet ein Austausch von Gedanken, Meinungen und Gefühlen statt. Der Dialog findet über einen Zeitraum statt, insbesondere wenn eine Story geschätzt wird (während der Release Planung) und in der Sprint Planning (ggf. auch Sprint Planung Zwei), wenn sie für die Implementierung eingeplant wird. Der Dialog findet hauptsächlich verbal statt, kann aber durch Dokumente unterstützt werden. Am Besten sind dafür Beispiele geeignet, diese sollten ausführbar sein. Solche Beispiele werden Confirmation - Bestätigung genannt.

Confirmation - Bestätigung

Egal wie viel wir diskutieren oder dokumentieren, wir können nie ausreichend präzise sein, was getan werden muss. Der Punkt Confirmation - Bestätigung der Schlüsselaspekte der User Story - ergänzt Informationen, die dringend benötigt werden. Diese Komponente macht den Akzeptanztest aus.

INVEST

Buchstabe	Bedeutung	Beschreibung
I	Independent (unabhängig)	Die User Story sollte eigenständig sein und keine Abhängigkeiten von anderen User Stories beinhalten.
N	Negotiable (verhandelbar)	User Stories können jederzeit verändert und neu geschrieben werden - bis zum Zeitpunkt, wo sie Teil eines Sprints werden.
V	Valuable (wertvoll)	Eine User Story muss für einen Kunden werthaltig sein.
E	Estimable (schätzbar)	Eine User Story muss in ihrem Umfang geschätzt werden können.
S	Sized appropriately or Small (angemessene oder kleine Größe)	User Stories sollten nur so groß sein, dass sie geplant und priorisiert und mit Aufgaben präzisiert werden können und die Erfüllung mit einer bestimmten Wahrscheinlichkeit erreicht werden kann.
T	Testable (testbar)	Die User Story bzw. ihre Beschreibung muss die nötige Information für die Testentwicklung liefern.

Independent - unabhängig

Eine der Charakteristiken agiler Methoden wie Scrum ist die Fähigkeit, Storys z.B. auf Basis ihrer relativen Priorität ohne großen Aufwand zu verschieben. Wenn User Stories voneinander abhängen, ist es sinnvoll sie in eine einzige zu überführen.

Negotiable - verhandelbar

Das einzige Feststehende in einem Scrumprojekt ist der Sprint Backlog. Solange sich eine User Story noch im Product Backlog befindet, kann sie von Scrum Team Mitgliedern entsprechend der Geschäfts-, Markt- oder technischer Gegebenheiten oder anderer Anforderungen umgeschrieben oder sogar weggeworfen werden.

Valuable - wertvoll

Der Fokus liegt darauf, echten projektbezogenen Wert für den Kunden zu generieren. Das Heraufbeschwören technischer Stories, die zwar Vergnügen beim Programmieren, aber keine Wertsteigerung für den Kunden bringen, widersprechen dem Prinzip des Agilen Manifests, stetig werthaltige Software zu liefern. Zu den Prinzipien des Agilen Manifests siehe https://agilemanifesto.org/iso/de/principles.html 

Estimable - schätzbar

Wenn eine User Story nicht geschätzt werden kann, kann sie nicht geplant, mit Aufgaben versehen werden und damit Teil eines Sprints werden. Es macht keinen Sinn, eine solche User Story im Product Backlog zu behalten. Meistens liegt die nicht ausreichende Schätzbarkeit daran, dass nicht genügend Information in der Beschreibung der User Story selbst oder vom Product Owner:in zur Verfügung gestellt wird.

 

Sized appropriately or Small - angemessene oder kleine Größe

User Stories sollten möglichst nur 13 Storypunkte oder kleiner sein. Alles jenseits dieser Größenordnung ist üblicherweise zu groß für eine hinreichend genaue Schätzung und sollte in kleinere Einheiten unterteilt werden. Es ist kein Problem mit großen Stories ("Epics") anzufangen, wenn sie in kleinere User Storys aufgeteilt werden, sobald der Zeitpunkt für die Einplanung in den Sprint Backlog gekommen ist.

 

Testable - testbar

Eine User Story ist erst dann fertig, wenn sie erfolgreich getestet wurde. Wenn sie wegen fehlender Information nicht getestet werden kann (siehe estimable - schätzbar weiter oben), sollte diese User Story auch nicht in den Sprint Backlog aufgenommen werden. Dies betrifft vor allem Teams ,die [[Test-driven development|TDD - Test Driven Development]] anwenden.