t2informatik » Wissen kompakt » User Story

Was ist eine User Story?

Wie wird sie formuliert, wie schätzen Sie den Aufwand und wo liegen Unterschiede zu Use Cases?

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

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 für ihn zu erzeugen.

Beispiele für eine User Story

  • 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 dieses Kino Tickets online buchen zu können.

Selbst mit der empfohlenen Satzstruktur können User Storys unterschiedlich detailliert sein. Sie können sie relativ grob und nach und nach mit zusätzlichen Details verstehen, so lange, bis sie detailliert genug ist, um sie umzusetzen.

User Story Whitepaper - t2informatik 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 »

Der Unterschied von User Storys und ….

Epics und 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 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.

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.

Lastenhefte und Pflichtenhefte

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  Kommunikationsprobleme 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.

Wollen Sie mehr über User Storys erfahren?

Dann erfahren Sie hier mehr die Verwaltung von User Storys in Backlogs, die Herausforderungen beim Backlog Grooming oder die Vorteile des User Story Mappings.

Herausforderungen für Unternehmen

Den Aufwand einer User Story 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ätzbare 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 vermieden.

Akzeptanzkriterien einer User Story

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.

Das 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.

Gerne stellen wir Ihnen Wissen, Erfahrung und 100% Leidenschaft für Ihre Softwareentwicklung und Anforderungsanalyse zur Verfügung. Wir helfen Ihnen bei der Erhebung, Strukturierung und Verwaltung von Anforderungen und achten dabei auf Konsistenz, Vollständigkeit und Nachvollziehbarkeit. Wir unterstützen Sie beim Arbeiten mit Backlogs. Und wir planen und steuern Ihre Projekte mit Ihren Anforderungen auf Basis definierter Prozesse.

Hier erfahren Sie mehr zum Thema Softwareentwicklung »

Weitere Details und Hintergründe

Share This