User Story. Funktionalität aus der Sicht des Anwenders erzählen.
Wofür braucht man eine User Story? Welche Vorteile haben User Storys und was müssen Sie für die Erstellung beachten?
Mit einer User Story beschreiben Sie Funktionalitäten an das System aus der Sicht des Anwenders. Sie dient als Basis, um Anforderungen zu finden.
Eine User Story wird in 1 bis 2 Sätzen formuliert und besitzt immer eine bestimmte Struktur, die das Wer, Was und Warum ausrückt. Außerdem lassen sich zusätzlich die Akzeptanzkriterien auflisten.
Was ist eine User Story?
Eine User Story erzählt eine kurze Geschichte aus der Sicht des Anwenders, um eine gewünschte Funktionalität an das System zu beschreiben. Für diesen Zweck konzentrieren Sie sich nur auf das Was und schreiben Ihre Geschichte in einfacher Sprache, damit sie alle Beteiligten ohne technischen Hintergrund verstehen können. Denn die User Story soll die Brücke zwischen Entwicklung und Kunden bilden. Wie genau Sie die Funktionalität umsetzen, ist für eine User Story unerheblich. Eine User Story ist außerdem flexibel und passt sich neuen Erkenntnissen an: Sie lässt sich somit erst grob erfassen und mit mehr und mehr Details füllen, bis sie detailliert genug ist, um sie umzusetzen. Ziel einer User Story ist es immer, einen Mehrwert für den Kunden zu schaffen.
Definition einer User Story:
Eine User Story ist ein Werkzeug im agilen Projektmanagement, um Funktionalitäten an das System aus der Sicht des Anwenders zu beschreiben. Sie dient als Basis, um Anforderungen zu finden.
Unterschied zwischen User Story und Use Case
Wenn Sie agil arbeiten, dann setzen Sie auch häufig sogenannte Use Cases ein: Sie beschreiben, wie Anwender (Akteure) mit dem zu entwickelnden System interagieren. Use Cases sind sehr beliebt, da sie wie auch User Storys eine Grundlage bilden, um Anforderungen an das Produkt zu finden. Außerdem ist ihr Ziel ebenfalls, dem Anwender bzw. Stakeholder Mehrwert zu schaffen. Worin also unterscheiden sich Use Cases von User Storys? Use Cases sind sehr umfangreich, weil sie Informationen zum gesamten Kontext bieten. Sie sind langlebig und werden während des gesamten Projekts gepflegt, während User Storys häufig nur eine Iteration lang “überleben”. Eignet sich dann das eine Hilfsmittel mehr als das andere oder schließen sie sich beide gar aus? Die Antwort lautet: Nein, Use Cases und User Storys schaffen nur unterschiedliche Perspektiven auf das System und ergänzen sich sehr gut. Daher lohnt es sich, beide Werkzeuge zusammen für Ihre Projekte einzusetzen. Zum Beispiel eignen sich User Storys, um Szenarien von Use Cases zu verstehen und abzubilden. Durch die Kombination beider Methoden können Sie Ihre Anforderungen leichter und genauer definieren.
Um Use Cases wie User Storys auch als Planungsinstrumente zu verwenden, kann man sie in kleinere Use Case Slices “zerschneiden”. Diese Vorgehensweise ist durch den Use Case 2.0-Ansatz entstanden.
Merkmale User Story
- Ziel: Mehrwert schaffen
- Kurz, klein und kompakt
- Leichtgewichtig
- Gleicht Szenario eines Use Cases
- Kurzlebig, leben nur in der Iteration
Merkmale Use Case
- Ziel: Mehrwert schaffen
- Detailliert, groß, deckt Kontext ab
- Umfangreich
- Fasst mehrere User Storys zusammen
- Langlebig, bestehen so lang, wie man Produkt entwickelt
Gut zu wissen:
Die User Story fand Ihren Ursprung im Extreme Programming (XP). Mittlerweile sind User Storys ein beliebtes Hilfsmittel in anderen agilen Methoden wie Scrum.
So arbeiten Sie mit User Storys in der Praxis
Erfahren Sie hier mehr zu Agilität
mit objectiF RPM »
So erstellen Sie eine User Story
Um die Geschichten Ihrer User Storys schreiben zu können, brauchen Sie Informationen. Diese finden Sie zum Beispiel im Gespräch und der Beobachtung von Anwendern oder durch Fragebögen. Und dann formulieren Sie den Inhalt der User Storys.
Dieser Inhalt besteht aus 1 – 2 Sätzen und besitzt immer eine bestimmte Struktur. Traditionell arbeiten agile Projekte wie zum Beispiel Scrum-Projekte mit Karteikärtchen, auf denen Sie die Funktionalität beschreiben. Zur Erleichterung der Planung und Erstellung setzt man auch häufig Software ein, die Vorlagen für User Storys bieten.
Vorlage und Beispiele einer User Story
Um eine User Story zu schreiben, verwenden Sie folgende Vorlage:
Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen.
Durch diese Struktur klärt die User Story die wichtigen Fragen nach dem Wer, Was und Warum. Für die Formulierung müssen Sie immer darauf achten, tatsächlich aus der Sicht des Kunden zu schreiben und einen wirklichen Nutzen für Sie zu erzeugen. Zum Beispiel:
- Als Bankautomat-Nutzer möchte ich Geld abheben, um mit Bargeld bezahlen zu können.
- Als Bankautomat-Nutzer möchte ich meinen Kontostand einsehen, um entscheiden zu können, wie viel ich abheben will.
Vielleicht bemerken Sie, wie breit gefasst die erste User Story wirkt, während die letzte spezifischer ist. Das ist normal, da Sie sich oftmals von den größeren Problemen zu den kleineren durcharbeiten.
User Storys können sich daher in ihrem Umfang unterscheiden. Um diesen Umstand zu berücksichtigen, sind Klassifizierungen entstanden: Features, Epics und User Storys.
Unterschied zwischen Feature, Epic, User Story
Die Unterscheidung nach Features, Epics und User Storys ist nicht standardisiert. Jede Organisation bzw. jedes Projekt kann entscheiden, ob und wie sie User Storys klassifiziert. Zum Beispiel gibt es folgende Einteilung:
Features: beschreiben Funktionalitäten auf dem höchsten fachlichen Niveau.
Epics: verfeinern die Funktionalitäten von Features, sind aber noch zu umfangreich, um sie in einer Iteration umzusetzen; planbar für Releases.
User Story: verfeinern Epics und lassen sich für Sprints einplanen, sind also in ein paar Tagen oder Wochen implementierbar.
Um Features und Epics in kleine User Story zu zerlegen, verfeinern Sie diese nach bestimmten Prinzipien. Zum Beispiel:
- nach Workflows
- nach Aufwänden (hoch vs. gering)
- nach Komplexität
- nach Spike Storys
Aber wie genau stellen Sie fest, ob Sie eine geeignete User Story definiert haben? Reicht ein „Ich denke, das passt so“? Um nach objektiveren Kriterien zu entscheiden, können Sie sich am INVEST-Prinzip von Bill Wake orientieren.
User Storys und das INVEST-Prinzip
| Independent | Unabhängig | User Story kann für sich stehen, ohne von anderen User Storys abhängig zu sein. |
| Negotiable | Verhandelbar | User Story umfasst am Anfang wenige Details und wird nach und nach in Diskussion detaillierter. |
| Valuable | Wertvoll | User Story bringt Anwender/Kunden einen Mehrwert. |
| Estimable | Schätzbar | Aufwand der User Story lässt sich durch Entwickler schätzen. |
| Small | Klein | User Story muss innerhalb einer Iteration implementierbar sein. |
| Testable | Testbar | User Story muss sich überprüfen lassen können. |
Was sind die Akzeptanzkriterien einer User Story?
Sie müssen die Umsetzung einer User Story prüfen können. Aber wie wissen Sie, ob diese vollständig implementiert ist? Die Antwort darauf lautet: Sie definieren Akzeptanzkriterien für die User Story – also stichpunktartige Ergebnisse, die Ihre User Story liefern muss.
Mit diesen Kriterien kann der Product Owner die User Storys später abnehmen, indem er die Punkte dieser Checkliste einfach abhakt. Die Akzeptanzkriterien entwickeln sich von groben Stichpunkten zu einem umfangreichen Akzeptanztest, in dem Sie die User Storys durch Testfälle prüfen.
Wie schätzen Sie den Aufwand einer User Story?
Um den Aufwand einer User Story zu schätzen, eignen sich zwei Methoden: Story Points und Personentage. Story Points werden gern in agilen Projekten eingesetzt und entsprechen einfachen Zahlen, zum Beispiel Fibonacci-Zahlen (1, 2, 3, 5, 8 etc.). Je höher der Aufwand einer User Story ist, desto größer ist die Zahl. Dadurch ergeben sich zur Schätzung relative Werte: eine User Story mit dem Aufwand von 2 ist zum Beispiel schneller erledigt ist als eine mit 8.
In vielen Projekten arbeitet man jedoch sowohl agil als auch klassisch, d.h. Sie rechnen zusätzlich in Stunden oder Personentagen, damit Sie die Dauer und Kosten Ihrer Aktivitäten bestimmen können. Um dieses hybride Projektmanagement umzusetzen, sollten Sie die klassische Aufwandsschätzung mit Personentagen für User Storys verwenden.
Lesen Sie hier, um mehr über hybrides Projektmanagement zu erfahren »
Technical Storys und Spike Storys
Neben User Storys setzen Entwicklungsteams häufig auch sogenannte Technical Storys ein. Diese Storys beschreiben keine Funktionalität, sondern Kriterien, die den technischen Aufwand hinter einer User Story verdeutlichen. Ähnlich wie bei Misuse Cases versuchen Sie also durch Technical Storys, nicht-funktionale Anforderungen zu bestimmen, zum Beispiel bezüglich Sicherheit, Performance oder Skalierbarkeit. Wenn Sie auch Technical Storys einsetzen wollen, müssen Sie auf eine klare Trennung von User Storys und Technical Storys – zum Beispiel durch eine Kennzeichnung – achten. Dadurch vermeiden Sie Missverständnisse bei der Priorisierung.
Sollten Ihnen Informationen bzw. Kenntnisse zu einer User Story fehlen, so lassen sich sogenannte Spike Storys erstellen: Sie formulieren eine Frage, die Sie beantworten oder eine Recherche, die Sie durchführen müssen. Dadurch können Sie dann eine User Story schätzbar und planbar machen. Zum Beispiel würde die Vorlage einer Spike Story folgendermaßen lauten:
Um (Ziel zu erreichen), muss (System oder Rolle) (Handlung) tun.
Wissen zum Mitnehmen
Alles über User Storys, Backlogs und Backlog Grooming kompakt
Vorteile von User Storys zusammengefasst
User Storys …
machen Wünsche und Ziele der Stakeholder für Entwickler greifbarer
unterstützen iterative Entwicklung
sind schnell erstellt
haben eine kurze und verständliche Struktur und Sprache
erleichtern die Schätzung
Detaillierungsgrad darf variieren (Feature, Epic, User Story)
Mit User Storys zu den Funktionalitäten
User Storys führen Entwickler und Stakeholder zusammen, weil sie Funktionalitäten des Systems einfach verständlich beschreiben. Sie sind kurz formuliert, lassen sich schnell erstellen und ergänzen die Entwicklung mit Use Cases. Aber wie handhaben Sie eine große Anzahl von User Storys, ohne den Überblick zu verlieren? Wie schätzen Sie die Aufwände und planen die Storys für den nächsten Sprint? Wie verfeinern Sie Features und Epics und stellen die Rückverfolgbarkeit sowie Testbarkeit der User Story jederzeit sicher? Und was passiert, wenn Sie Änderungen einpflegen müssen oder mit Technical und Spike Storys arbeiten wollen? Mit einer Software können Sie eine Vorlage nutzen, um User Storys schnell anzulegen, ihre Aufwände zu schätzen und Backlogs bzw. Sprints zuzuordnen. Wenn Sie Features, Epics, Technical oder Spike Storys anlegen wollen, lassen diese sich genau kennzeichnen und ggf. in User Storys verfeinern – immer rückverfolgbar und für jeden Projektbeteiligten nachvollziehbar. Und auch Testfälle können Sie mit wenigen Klicks mit den User Storys verbinden, damit sich die Implementierung der Funktionalitäten prüfen lässt.