User Story

Als Konzept geht die User Story auf Extreme Programming (XP) – und nicht wie häufig angenommen auf den Scrum Guide – zurück. Extreme Programming ist ein agiles Entwicklungsmodell, das Mitte der 1990er Jahre in einem Projekt bei Chrysler von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt wurde.¹

Tipps zum Schreiben einer User Story

Im Gegensatz zu einer Geschichte, die an einem Lagerfeuer erzählt wird, sollte eine User Story in kurzen Sätzen und mit einfachen Worten beschrieben werden. So stellen Sie sicher, dass alle an Ihrer Entwicklung beteiligten Kollegen sie auch ohne technischen Hintergrund verstehen. Es geht vor allem um

• WER,
• WAS und
• WARUM,

also wer möchte was von einem System, um welchen Nutzen davon zu haben. Wie die gewünschte Funktionalität später umgesetzt wird, ist für die Beschreibung unerheblich. Beim Schreiben wird häufig folgende Satzschablone genutzt:

Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen.

Hier finden Sie einige Beispiele:

• Als Filmliebhaber möchte ich über neue Filme informiert werden, um zu wissen, welche Filme als nächstes im Kino laufen.
• Als Filmliebhaber möchte ich einmal pro Woche einen Newsletter erhalten, um zu wissen, welche Filme als nächstes im Kino laufen.
• Als Filmliebhaber möchte ich einmal pro Woche per Mail über neue Science Fiction Filme informiert werden, die im Colosseum Kino in Berlin laufen, um mir für entsprechende Filme in diesem Kino Tickets online buchen zu können.

Selbst mit der empfohlenen Satzstruktur können Beschreibungen unterschiedlich detailliert sein. Eine initiale User Story kann relativ grob formuliert sein, bevor sie im Zuge einer Verfeinerung schrittweise detailliert wird, bis zum Schluss die Beteiligten verstehen, warum es konkret geht und wo der Nutzen genau liegt.

Alternative User Story Satzschablonen

Neben der weitverbreiteten Satzschablone “Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen.” gibt es noch einige Alternativen²:

“Um (Nutzen) als (Rolle) zu erreichen, möchte ich (Funktionalität/Ziel/Wunsch).”
“In order to (receive benefit) as a (role), I can (goal/desire).”

Diese Formulierung geht auf Chris Matts, einen englischen Programmierer und Experten im Kontext von Agile und Lean Management zurück, der den Wert bzw. Nutzen vor die Funktionalität stellt.

“Als (Rolle) möchte ich (was) (warum).”
As (user role), I can (what) so that (why).”

Diese Formulierung geht auf Rachel Davies, einer Agile Expertin zurück.

“Als (wer) (wann) (wo) möchte ich (was) (warum).”
“As (who) (when) (where), I (want) because (why).”

Diese Formulierung basiert auf typischen W-Fragen: wer, wann, wo, was, warum.

“Als (Persona) möchte ich (was) warum.”
“As (persona), I want (what) so that (why).”

Diese Formulierung geht auf Roman Pichler, einen Produktmanagement-Fachmann, zurück.

Unabhängig von den feinen Unterschieden, ist es empfehlenswert sich für eine Alternative zu entscheiden und die entsprechende Satzschablone beizubehalten. Das erleichtert das Formulieren und fördert das Verständnis der Beteiligten.

Qualitative User Storys mit dem INVEST-Prinzip

Wie stellen Sie fest, ob Sie eine qualitativ gute User Story definiert haben? William Wake bietet mithilfe des INVEST-Prinzips eine gute Orientierung bei der Formulierung.

INVEST ist ein Akronym:

• Independent: Die User Story steht für sich und ist unabhängig von anderen Storys.
• Negotiable: Der Inhalt ist verhandelbar und wird nach und nach detaillierter beschrieben, bis sie sich umsetzen lässt.
• Valuable: Sie ist wertvoll und bietet dem Anwender oder Kunden einen Mehrwert bzw. Nutzen.
• Estimable: Der Aufwand zur Realisierung muss sich durch die Entwickler schätzen lassen.
• Small: Sie ist so klein, dass sie innerhalb einer Iteration bzw. eines Sprints realisierbar ist.
• Testable: Sie verfügt über Akzeptanzkriterien und ist prüfbar.

Die Aufwandsschätzung zur Realisierung einer User Story

User Storys werden häufig in Personentagen oder mittels sogenannter Story Points geschätzt. Beim Arbeiten mit Story Points bestimmt das Entwicklungsteam ein Kriterium oder eine Verknüpfung von mehreren Kriterien, um die Größe einer Story festzulegen. Ein solches Kriterium könnte Komplexität sein, bspw. in Bezug auf die Verwendung von verschiedenen Schichten des Architekturmodells. Es geht also nicht um die Zeit, die zur Umsetzung benötigt wird, sondern um strukturelle Eigenschaften. Natürlich kann ein erfahrenes Entwicklungsteam im Vergleich zu einem weniger erfahrenen Team größere Items in einem Sprint umsetzen, doch die Größe der Story bleibt davon unberührt. In anderen Worten: die Eigenschaften einer User Story hängen nicht von den Fähigkeiten des Teams ab.

In Scrum drückt die sogenannte Velocity aus, wie viele Story Points ein Team pro Iteration umsetzt, so dass auch beim Arbeiten mit Story Points Aussagen getroffen werden können, in welcher Iteration ein Feature geliefert wird.³ In der Praxis können Merkmale einer User Story häufig ohne detaillierte Tätigkeitenanalyse identifiziert werden. Dies ist ein wesentlicher Unterschied zu der Aufwandsschätzung in Personentagen, bei der alle notwendigen Tätigkeiten identifiziert und summiert werden. Oft wird eine User Story mit mittlerer Größe als Referenz ausgewählt und die Schätzung im Vergleich zu dieser Referenz durchgeführt. Als Wertebereich dient eine Fibonacci-Reihe bis 13, ergänzt mit 20, 40 und 100, wobei 1 einer Aufgabe mit niedriger Komplexität und 100 einer noch nicht einschätzbaren Aufgabe entspricht.

User Story Splitting

Bevor ein Sprint beginnen kann, müssen die ausgewählten User Storys klein genug sein, um innerhalb des Sprints realisiert werden. Damit dies gelingt, werden einzelne Storys zerlegt, der gängige Begriff dafür lautet User Story Splitting. Das Splitting sollte sich dabei stets an dem Nutzen des Anwenders und nicht an der Technik orientieren.

Idealerweise wird es nicht alleine von einen Product Owner sondern vom gesamten Team – zumindest aber mit mehreren Teammitgliedern – durchgeführt. So lassen sich unnötige Abhängigkeiten zwischen einzelnen Items, die frühzeitige Beschreibung von Lösungsansätzen und die übermäßige Produktion von Spike Storys vermeiden.

User Story Akzeptanzkriterien

Wann wissen Sie, ob eine User Story vollständig implementiert wurde? Hier helfen Akzeptanzkriterien. Mit diesen legen Sie stichpunktartig Ergebnisse fest, die im Zuge der Implementierung erfüllt werden müssen.

Akzeptanzkriterien gelten als Bindeglied zwischen User Storys und Testfällen. Eine Möglichkeit, Akzeptanzkriterien zu definieren, ist das Hinterfragen von Schlüsselwörtern, also Verben, Adjektiven und Substantiven. Beispiel:

“Als Kinobesucher möchte ich meine gekauften Tickets in meinem Profil speichern, damit ich nachvollziehen kann, welche Filme ich gesehen habe.”

• Wer speichert was, wann, wo?
• Was geschieht bei der Speicherung eines neuen Tickets mit bereits gespeicherten Informationen?
• Wie viele Tickets sollen gespeichert werden können?

Mit solchen W-Fragen finden Sie Akzeptanzkriterien. Als Checkliste sind sie eine gute Basis für die Entwicklung von umfangreichen Testfällen.

Abhängigkeiten zwischen User Storys

User Storys sollten – wie es das INVEST-Prinzip fordert, unabhängig voneinander sein. In der Praxis gibt es jedoch in Bezug auf die Umsetzung immer wieder

• inhaltliche bzw. fachliche,
• technische,
• zeitliche oder
• normative bzw. regulatorische Abhängigkeiten.

Indirekt können auch unterschiedliche Kompetenzen einzelner Teammitglieder zu Abhängigkeiten führen. Auch wenn ein Team als Ganzes wirkt, so haben einzelne Mitarbeiter in gewissen Bereichen häufig mehr Kompetenzen als andere und die Übertragung dieser Kompetenzen funktioniert nicht immer so einfach, wie sich Teams dies oftmals wünschen würden.

Zur Visualisierung von Abhängigkeiten eignet sich das User Story Mapping am besten. Alternativ können Abhängigkeiten auch in separaten Tabellen oder mithilfe ergänzender Notizen dokumentiert werden.

User Story Verwaltung im Product Backlog: DEEP

User Storys werden in Backlogs verwaltet. Hier kommt das Akronym DEEP zum Tragen, das Roman Pichler in seinem Buch “Agile Product Management with Scrum”⁴ erläutert:

• Detailed Appropriately (angemessen detailliert): User Storys, die demnächst umgesetzt werden sollen, müssen detaillierter ausgearbeitet sein als jene, die erst zu einem späteren Zeitpunkt umgesetzt werden sollen.
• Estimated (geschätzt): Backlog Items werden geschätzt, wobei Items mit höherer Priorität zunächst detaillierter geschätzt werden als Items mit niedrigerer Priorität.
• Emergent (entstehend): Im Laufe von Entwicklungen werden neue Informationen und Erkenntnisse gewonnen. Entsprechende Items werden folglich im Produkt Backlog hinzugefügt, entfernt oder neu geordnet.
• Prioritized (priorisiert): Alle Items werden im Backlog nach Priorität geordnet. Ziel ist es, die wichtigsten zuerst zu implementieren.

DEEP gilt als nützliches Konzept, das die kontinuierliche Arbeit mit Backlog Items betont.

Die Abgrenzung von User Storys zu anderen Hilfsmitteln

Der unterschiedliche Umfang von Funktionalitäten eines Systems und Nutzen aus Sicht eines Anwenders führt häufig zu den Kategorisierungen Epics, Feature und User Story. Die Unterscheidung in diese drei Kategorien ist jedoch nicht standardisiert, d. h. in manchen Unternehmen sind Features bspw. umfangreicher als Epics. Wichtig ist daher, dass es ein einheitliches Verständnis im Unternehmen gibt. Die Unterscheidung könnte bspw. wie folgt aussehen:

Epics beschreiben Funktionalitäten auf höchstem fachlichen Niveau.

Features verfeinern die Funktionalitäten von Epics und lassen sich für die Release-Planung verwenden. Sie sind aber noch zu umfangreich, um in einer Iteration bzw. einem Sprint umgesetzt zu werden.

User Storys verfeinern Features und lassen sich in Sprints einplanen und umsetzen.

Und was ist der Unterschied zu einem Use Case, mit dem auch beschrieben wird, wie ein Akteur mit einem zu entwickelnden System interagiert? Ein Use Case deckt einen Kontext ab und ist damit umfangreicher. Er umfasst somit mehrere User Storys und ist deutlich langlebiger, d.h. er wird über die gesamte Systementwicklung gepflegt, während die User Story mit ihrer Implementierung in einem Sprint praktisch verschwindet.

Beide Ansätze ergänzen sich in der Entwicklungspraxis sehr gut. Durch die Kombination beider Methoden lassen sich Anforderungen genauer verstehen. Um Use Cases in eine Sprint-Planung aufzunehmen, muss man sie zu Use Cases Slices zerschneiden. Diese Technik nennt sich Use Case 2.0.

Wo liegen Unterschiede zu Technical Storys? Entwicklungsteams nutzen oft auch Technical Storys. Mit ihnen werden weder Funktionalitäten noch ein Nutzen eines Anwenders beschrieben, sondern Kriterien, die den technischen Aufwand hinter einer User Story festhalten. So versuchen Entwicklungsteams nicht-funktionale Anforderungen bspw. bezüglich Performance, Skalierung, Sicherheit oder Verfügbarkeit zu definieren. Wichtig ist bei der Erfassung, dass es eine eindeutige Trennung von beiden Typen gibt. Durch eine entsprechende Kennzeichnung vermeiden Sie Missverständnisse bei der Priorisierung und Sprint-Planung bspw. im Rahmen eines Mappings.

Und was ist der Unterschied zu einer Spike Story? Eine Spike Story wird verwendet, um eine funktionale oder technische Anforderung besser zu verstehen und Unsicherheiten zu beseitigen. Sie ist ein Auftrag für eine Analyse, mit der eine Frage beantwortet, Informationen gesammelt oder Projektrisiken adressiert werden. Ihr Aufwand wird nicht geschätzt. Das Entwicklungsteam verpflichtet sich, eine bestimmte Zeit zu investieren, um die notwendige Analyse durchzuführen. Das Ergebnis führt zu einer Verfeinerung der Beschreibung, einem Splitting in kleinere Einheiten oder der Formulierung einer gänzlich neuen User Story.

Impuls zum Diskutieren:

Wie wichtig ist es in der Praxis, dass tatsächlich ein User seine Story formuliert, statt eines Stellverstreters, der dessen Perspektive einzunehmen versucht?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Im Zuge dessen wurden auch die 3 C’s eingeführt: Cards, Conversation und Confirmation. Auf Cards bzw. Karten werden die User Storys geschrieben. Eine Karte bildet die Grundlage für ein Gespräch (Conversation). Und Confirmation meint die Akzeptanzkriterien, die erfüllt und getestet werden müssen, um sicherzustellen, dass die gewünschte Funktionalität korrekt geliefert wird.
[2] Es gibt eine Satzschablone, die hilft, Technische Schulden zu adressieren: “If we don’t do this <action>, it will cause <impact> and that will result in <damage>.” Manchmal wird diese Form der Beschreibung als Negative User Story bezeichnet.
[3] Im Scrum Guide werden weder Velocity, User Storys, Story Points oder Akzeptanzkriterien erwähnt. Nichtsdestotrotz kommen diese Hilfsmittel in vielen Organisationen zum Einsatz.
[4] Agile Product Development with Scrum

Hier finden Sie einen Podcast User Storys – mehr als nur ein Template.

Und hier finden Sie ergänzende Informationen aus unserem t2informatik Blog:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.