User Story

Was ist eine User Story, wie wird sie formuliert, welche Beispiele gibt es und wie wichtig sind Akzeptanzkriterien?

User Story Definition

Der Begriff „User Story“ stammt aus dem Englischen. Das Wort user bedeutet Anwender oder Benutzerstory bedeutet Geschichte. Im wörtlichen Sinne beschreibt eine User Story also eine Geschichte eines Anwenders. Im agilen Projektmanagement und der Softwareentwicklung ist eine User Story ein Werkzeug, um gewünschte Funktionalitäten eines Systems aus Sicht des Anwenders zu beschreiben. Dabei bietet eine User Story vor allem drei Vorteile:

  • sie ist leicht zu verstehen und vermittelt die Wünsche der Anwender
  • sie ist schnell erstellt und erleichtert die Schätzung des Aufwands zur Realisierung
  • sie lässt sich schrittweise detaillieren und unterstützt so die iterative Entwicklung

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, dass zwischen 1995 und 2000 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 Sie an einem Lagerfeuer erzählen, 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 eine User Story unerheblich. Beim Schreiben einer User Story empfiehlt sich folgende Satzstruktur:

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

Achten Sie bei der Formulierung darauf, sie aus der Sicht des Anwenders, Benutzers oder Kunden zu schreiben, und einen wirklichen Nutzen zu benennen.

User Story

User Story Beispiele

Hier finden Sie einige Beispiele für User Storys:

  • 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 laufen, um mir für entsprechende Filme in diesem Kino Tickets online buchen zu können.

Selbst mit der empfohlenen Satzstruktur können User Storys 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

User Storys werden von oder für Anwender oder Kunden geschrieben, um die Funktionalität des zu entwickelnden Systems zu beeinflussen. Neben der am häufigsten genutzten 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).“
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. Das englische Original lautet: „In order to (receive benefit) as a (role), I can (goal/desire).“

„Als (Rolle) möchte ich (was) (warum).“
Diese Formulierung geht auf Rachel Davies, einer Agile Expertin zurück. Das englische Orginal lautet: „As (user role), I can (what) so that (why).“

„Als (wer) (wann) (wo) möchte ich (was) (warum).“
Diese Formulierung basiert auf typischen W-Fragen: wer, wann, wo, was, warum. Das englische Original lautet: „As (who) (when) (where), I (want) because (why).“

„Als (Persona) möchte ich (was) warum.“
Diese Formulierung geht auf Roman Pichler, einen Produktmanagement-Fachmann, zurück. Das englische Original lautet: „As (persona), I want (what) so that (why).“ 

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 von User Storys und fördert das Verständnis. 

User Story Whitepaper Download

Jetzt das User Story Whitepaper kostenlos downloaden.

Alles Wichtige über User Storys, Unterschiede zu Use Cases und User Story Mapping auf 11 Seiten zum Mitnehmen.

Hier klicken »

User Storys in der Praxis

User Story Aufwand schätzen

Wie schätzen Sie den Aufwand einer User Story? Die Antwortet lautet: in Personentagen oder mit Story Points. Beim Arbeiten mit Story Points bestimmt das Entwicklungsteam ein Kriterium oder eine Verknüpfung von mehreren Kriterien, um die Größe der User Story festzulegen. Ein solches Kriterium könnte Komplexität sein, bspw. in Bezug auf die Verwendung von verschiedenen Schichten des Architekturmodells. Es geht also bei Story Points nicht um die Zeit, die zur Umsetzung der User Story benötigt wird, sondern um die strukturellen Eigenschaften einer User Story. Natürlich kann ein erfahrenes Entwicklungsteam im Vergleich zu einem weniger erfahrenen Team größere User Storys 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. Das User Story Splitting ist daher eine wichtige Aufgabe. Es sollte sich an dem Nutzen des Anwenders („Als [Rolle] möchte ich [Funktionalität], um [Nutzen] zu erreichen.“) 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 User Storys, 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 Akzeptanzkriterien legen Sie stichpunktartig Ergebnisse fest, die durch die User Story 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 leicht Akzeptanzkriterien. Als Checkliste sind sie eine gute Basis für die Entwicklung von umfangreichen Testfällen.

INVEST-Prinzip von William Wake

Wie stellen Sie fest, ob Sie eine qualitativ gute User Story definiert haben? William Wake bietet mit seinem INVEST-Prinzip Hilfe bei der Formulierung von User Storys. INVEST ist ein Akronym:

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

 

User Storys im Vergleich zu anderen Konzepten

User Storys vs. Epics oder Features

Der unterschiedliche Umfang von Funktionalitäten eines Systems und Nutzen aus Sicht eines Anwenders führt häufig zu den Kategorisierungen Epic, 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 im Unternehmen ein einheitliches Verständnis gibt. Die Unterscheidung zwischen Epics, Features und User Storys 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.

User Storys vs. Use Cases

Mit einem Use Case beschreiben Sie, wie ein Akteur mit einem zu entwickelnden System interagiert. Use Cases sind sehr beliebt, denn sie ermöglichen ebenso wie User Storys die Erhebung von Anforderungen an ein System. Und beide verfolgen das Ziel, einen Mehrwert für den Anwender zu schaffen. Worin liegen aber die Unterschiede zwischen Use Cases und User Storys?

Ein Use Case ist ist größer und detaillierter als eine User Story. Er deckt einen Kontext ab und ist damit umfangreicher. Er umfasst somit mehrere User Storys. Und er ist deutlich langlebiger, d.h. er wird über die gesamte Systementwicklung gepflegt, während die User Story mit ihrer Erledigung in einem Sprint praktisch verschwindet.

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

User Storys vs. Lastenhefte

In einem Lastenheft beschreibt ein Kunde seine Wünsche an ein zu entwickelndes System. Dabei landen die Systemanforderungen im Lastenheft, während die Projektanforderungen wie Budgets, Terminpläne, Meilensteine etc. im Projektauftrag oder ggfs. in einem Projekthandbuch festgehalten werden. Ein Pflichtenheft hat eine andere Funktion als ein Lastenheft, denn in ihm werden die Anforderungen aus dem Lastenheft geklärt und detailliert. Das Pflichtenheft kann klassisch als „System Requirements Specification“ oder im agilen Umfeld mit Epics, Features und User Storys vorliegen. Es kann somit wie ein Product Backlog verstanden werden.

Es kommt vor, dass von Softwareentwicklern geschriebene Pflichtenhefte für Fachabteilungen schwer verständlich sind. Solche Herausforderungen werden mit agilen Methoden wie Scrum adressiert. In Scrum hat der Product Owner die Aufgabe, aus den Epics, Features und User Storys genauso viele Anforderungen zu generieren, wie im nächsten Sprint realisiert werden können. Im Gegensatz zur Formulierung eines Lastenhefts wird die Vorlaufzeit zur Planung und Realisierung reduziert und die inhaltliche Flexibilität erhöht. Dieser Ansatz ist sehr pragmatisch, stellt aber Anforderungen auf anderen Ebenen wie bspw. Vertragsgestaltung, Aufwandsschätzung und Leistungsabrechnung.

Technical Storys und Spike Storys

Entwicklungsteams nutzen neben User Storys oft auch sogenannte 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 Technical Storys und User Storys gibt. Durch eine entsprechende Kennzeichnung vermeiden Sie Missverständnisse bei der Priorisierung und Sprint-Planung bspw. im Rahmen eines User Story Mappings.

Eine Spike Story ist eine Art User Story, die verwendet wird, um eine funktionale oder technische Anforderung besser zu verstehen, und so Unsicherheiten zu beseitigen. Sie ist ein Auftrag für eine Analyse, mit der eine Frage beantwortet, Informationen gesammelt oder Projektrisiken adressiert werden. Im Gegensatz zu einer User Story wird sie nicht geschätzt. Das Entwicklungsteam verpflichtet sich, eine bestimmte Zeit zu investieren, um die notwendige Analyse durchzuführen. Das Ergebnis führt zur Überarbeitung der User Story im Sinne einer Verfeinerung, einer Aufteilung in mehrere User Storys oder der Beschreibung einer gänzlich neuen User Story.

Hinweise:

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

Wissen kompakt: Wie funktioniert Scrum?

Wie funktioniert Scrum?

Wissen kompakt: Wie funktioniert Backlog Refinement?

Wie funktioniert Backlog Refinement?

Wissen kompakt: Wie funktioniert User Story Mapping?

Wie funktioniert User Story Mapping?