User Story – Definition, Aufbau und Beispiele

Was ist eine User Story?

User Stories sind eine Methode zur Beschreibung von Anforderungen in der Softwareentwicklung, insbesondere in agilen Entwicklungsmethoden wie Scrum, Agile und Extreme Programming (XP). Sie stellen eine einfache, klare Beschreibung einer Softwarefunktion aus der Perspektive des Endbenutzers dar. 

Das Ziel von User Stories besteht darin, die Diskussion zwischen Product Ownern oder Product Managern, Entwicklern und Stakeholdern (wie Business-Analysten und Endbenutzern) anzuregen. Sie sind bewusst kurz und offen formuliert, damit Raum für Fragen und Anpassungen besteht. Und es wird eine einfache, nicht technische Sprache verwendet, damit alle Beteiligten verstehen, worum es geht.

Wie sind User Stories aufgebaut?

Eine User Story besteht in der Regel aus drei Elementen:

1. Wer: Die Person oder Rolle, die die Funktion nutzen will. Dies könnte z. B. ein „Nutzer“, ein „Administrator“ oder eine spezifische Rolle wie „Buchhalter“ sein.

2. Was: Die Funktion oder Fähigkeit, die die vorher definierte Person nutzen will. Funktionen könnten zum Beispiel sein: „einen Umsatzbericht erstellen“, „ein Produkt in den Warenkorb legen“ oder „Passwort zurücksetzen“.

3. Warum: Das Ergebnis, das sich aus der Nutzung der Funktion ergibt. Dies könnte z. B. sein: „um den Umsatz nach Produktkategorie zu sehen“, „um einen Kauf abzuschließen“ oder „um Zugang zu meinem Konto wiederherzustellen“.

Ein Beispiel für eine User Story wäre also: „Als Buchhalter möchte ich einen Umsatzbericht erstellen können, um den Umsatz nach Produktkategorie zu sehen.“

Wer formuliert User Stories?

Auch wenn die User Story aus der Perspektive eines Nutzers formuliert ist, wird sie in der Regel vom Product Owner oder Product Manager erstellt. Diese kennen die Anforderungen und Bedürfnisse sowohl von Stakeholdern als auch von Endnutzers am besten. 

Im Scrum-Modell dienen Epics oft als Ausgangspunkt für User Stories – denn ein Epic kann aufgrund seiner Größe und Komplexität meist nicht innerhalb eines einzelnen Sprints abgeschlossen werden. User Stories bieten eine kleinere Einheit, die sich besser greifen und implementieren lässt.

Ausgehend vom ersten Entwurf einer User Story ist die Erstellung dann ein kollaborativer Prozess. Das Entwicklungsteam sollte früh in den Prozess einbezogen werden, um Fragen zu stellen, gemeinsam nach Lösungen zu suchen und technischen Input zu geben. Nur so können Teams sicher sein, dass User Stories realistisch, umsetzbar und im besten Interesse des Projekts sind.

Je nach Arbeitsweise und Kultur eines Unternehmens können bei Bedarf auch andere Mitglieder des Teams, QA-Teams oder sogar Endbenutzer an der Erstellung oder Überarbeitung von User Stories beteiligt sein.

Was ist der Unterschied zwischen einer User Story und einem Use Case? 

User Stories und Use Cases sind beides Techniken zur Darstellung von Anforderungen in der Softwareentwicklung, aber sie werden in unterschiedlichen Kontexten und mit unterschiedlichen Zielen verwendet. 

User Story:

• kurze, einfache Beschreibungen einer Funktion aus der Sicht eines Benutzers oder einer Rolle
• sollen Gespräche und Diskussionen über die Anforderungen anregen
• werden hauptsächlich in agilen Entwicklungsmethoden verwendet und sind dazu gedacht, in einer einzigen Iteration (wie einem Scrum-Sprint) umgesetzt zu werden
• konzentrieren sich auf das „Was“ (was der Benutzer erreichen will) und weniger auf das „Wie genau“

Use Case:

• detaillierte und formellere Beschreibungen von Funktionen 
• beschreiben Interaktionen zwischen Akteuren (die Benutzer oder andere Systeme sein können) und dem System
• enthalten typischerweise Szenarien oder Flussdiagramme, die beschreiben, wie das System auf die Aktionen des Akteurs reagieren sollte
• werden oft in traditionellen (plangetriebenen oder wasserfallartigen) Entwicklungsmethoden verwendet, können aber auch in agilen Kontexten nützlich sein, insbesondere bei komplexeren Funktionen
• konzentrieren sich sowohl auf das „Was“ als auch auf das „Wie“

Die beiden Techniken schließen sich nicht gegenseitig aus. In vielen Projekten kommen User Stories und Use Cases gemeinsam zum Einsatz. User Stories können zum Beispiel grobe Anforderungen und Prioritäten festlegen, während mit Use Cases spezifische Interaktionsdetails ausgearbeitet werden.

Wie schreibe ich gute User Stories?

Eine gute User Story ist kurz, klar und in Alltagssprache geschrieben. Der Fokus liegt auf dem, was der Benutzer erreichen möchte und warum – nicht auf technischen Details. Sie erfüllt die im Folgenden erklärten INVEST-Kriterien und wird durch Akzeptanzkriterien ergänzt.

INVEST-Kriterien

Welche Eigenschaften eine gute User Story erfüllen sollte, hat Bill Wake mit dem Akronym INVEST definiert. 

• Independent (Unabhängig): Jede User Story sollte unabhängig von anderen sein. Das heißt, sie sollte in beliebiger Reihenfolge umgesetzt werden können, ohne andere User Stories zu beeinflussen. Dies ermöglicht eine flexible Planung und Priorisierung.

• Negotiable (Verhandelbar): Eine User Story ist nicht eine detaillierte Spezifikation, sondern ein Gesprächsstarter. Details sollten durch Gespräche zwischen dem Entwicklungsteam und dem Stakeholder (oftmals der Product Owner) ausgehandelt werden.

• Valuable (Wertvoll): Jede User Story sollte einen klaren Wert für den Endbenutzer oder das Unternehmen liefern. Wenn eine Story keinen erkennbaren Wert hat, kannst Du sie verwerfen.

• Estimable (Schätzbar): Das Entwicklungsteam sollte in der Lage sein, die Komplexität einer User Story abzuschätzen, um zu entscheiden, wie viel Arbeit sie benötigt. Wenn eine Story zu groß oder zu kompliziert ist, um geschätzt zu werden, kannst Du sie in kleinere Stories teilen.

• Small (Klein): Eine gute User Story kann in einer einzigen Iteration (wie einem Sprint in Scrum) fertiggestellt werden.

• Testable (Testbar): Eine User Story sollte sich testen lassen, um zu bestätigen, dass sie richtig implementiert wurde. Hier kommen die Akzeptanzkriterien ins Spiel (nächstes Kapitel). 

Ein Beispiel für eine schlechte User Story 

Im Kontrast dazu hier eine User Story, die so in der Form keine gute Idee für ein Produktentwicklungsteam wäre: 

Als registrierter Benutzer möchte ich mein Profilbild hochladen und bearbeiten, damit andere Benutzer mein aktuelles Bild sehen können.

In dieser Story finden sich folgende Abhängigkeiten: 

1. Die User-Registrierung muss implementiert sein.
2. Eine Galerieansicht für Benutzerprofile muss vorhanden sein.
3. Ein Werkzeug zur Bildbearbeitung muss integriert sein.

Und aus diesen Gründen sollte diese User Story noch einmal überarbeitet werden: 

1. Komplexität: Die User Story versucht, mehrere Funktionen (Hochladen und Bearbeiten von Profilbildern) zu kombinieren. Für jede dieser Funktionen sollte stattdessen eine eigene Story formuliert werden. 

2. Innere Abhängigkeiten: Bevor ein Nutzer ein Profilbild hochladen kann, muss er sich registrieren können. Das macht diese Story von der Registrierungs-Story abhängig (sofern eine Registrierung nicht bereits umgesetzt wurde). 

3. Externe Abhängigkeiten: Die Erwähnung einer „Galerieansicht“ und eines „Bildbearbeitungs-Tools“ impliziert, dass andere Teams oder Features diese Funktionalitäten bereitstellen müssen, bevor diese Story abgeschlossen werden kann.

4. Fehlende Genauigkeit: Was bedeutet „Bild bearbeiten“? Beinhaltet das Zuschneiden, Farbanpassungen, Hinzufügen von Filtern oder andere Funktionen? Dies ist unklar und kann zur Verwirrung führen.

Eine bessere Herangehensweise wäre es, mehrere kleinere, unabhängige User Stories zu erstellen, wie:

• Als registrierter Benutzer möchte ich mein Profilbild hochladen, damit andere mein Bild sehen können.
• Als Benutzer möchte ich mein Profilbild zuschneiden können, um den Fokus auf bestimmte Bereiche zu legen.
• Als Benutzer möchte ich Filter auf mein Profilbild anwenden können, um es ästhetisch ansprechender zu machen.

Jede dieser Stories könnte dann einzeln priorisiert, geschätzt und in einem Sprint umgesetzt werden, wodurch die Abhängigkeiten minimiert und die Flexibilität erhöht wird.

Akzeptanzkriterien einer User Story

Auf den ersten Blick ist die Umsetzung einer User Story binär: Entweder der Buchhalter kann seinen Umsatzbericht erstellen, um den Umsatz nach Produktkategorie zu sehen – oder eben nicht. Doch wir alle haben nach Abschluss einer Aufgabe schon mal zu hören bekommen: „Nein, so hab ich das nicht gemeint!” 

Damit das nicht passiert, werden User Stories durch Akzeptanzkriterien ergänzt: spezifische Bedingungen, die weiter definieren, wann eine User Story korrekt abgeschlossen wurde. Akzeptanzkriterien sind eine Art Checkliste und enthalten pro Story normalerweise zwischen drei und zehn Punkten. 

Auch die Definition von Akzeptanzkriterien ist ein iterativer Prozess. Nicht selten kommt es vor, dass sie während der Umsetzung einer User Story weiter angepasst werden müssen – insbesondere, wenn neue Informationen oder Anforderungen auftauchen oder das Team merkt, dass es gewisse Gegebenheiten zuvor nicht bedacht hat. 

3 Beispiele für Akzeptanzkriterien

‍

User Story 1: Als Endbenutzer möchte ich mich auf der Website registrieren können, um Zugriff auf exklusive Inhalte zu erhalten.

Akzeptanzkriterien:

• Es gibt ein deutlich sichtbares Registrierungsformular auf der Startseite.
• Das Formular erfordert mindestens einen Nutzernamen, eine E-Mail-Adresse und ein Passwort.
• Nach erfolgreicher Registrierung erhält der Nutzer eine Bestätigungs-E-Mail.
• Wenn der Nutzer bereits registriert ist, erhält er eine entsprechende Fehlermeldung.

User Story 2: Als Administrator möchte ich alle registrierten Nutzer in einer übersichtlichen Liste sehen können, um nachzuvollziehen, wer welche Rechte hat.

Akzeptanzkriterien:

• Es gibt eine Admin-Seite, die nur nach erfolgreicher Anmeldung als Administrator zugänglich ist.
• Auf dieser Seite wird eine Liste aller registrierten Nutzer angezeigt.
• Für jeden Nutzer werden der Nutzername, die E-Mail-Adresse, das Registrierungsdatum und deren Rechte angezeigt.
• Es gibt eine Suchfunktion, um Nutzer anhand ihres Namens oder ihrer E-Mail-Adresse zu finden.

User Story 3: Als Nutzer möchte ich mein Passwort zurücksetzen können, damit ich auch dann noch auf meinen Account zugreifen kann, wenn ich es vergessen habe. 

Akzeptanzkriterien:

• Auf der Anmeldeseite gibt es einen „Passwort vergessen?“-Link.
• Nach Anklicken dieses Links wird der Nutzer aufgefordert, seine E-Mail-Adresse einzugeben.
• Wenn die eingegebene E-Mail-Adresse in der Datenbank vorhanden ist, erhält der Nutzer eine E-Mail mit einem Link zum Zurücksetzen des Passworts.
• Der Link zum Zurücksetzen des Passworts ist nur für eine begrenzte Zeit gültig (z. B. 24 Stunden).

User Stories bewerten, priorisieren und mit Story Cards umsetzen 

Eine der wichtigsten Fragen in der (agilen) Produktentwicklung ist: Was können wir streichen? Je größer der Berg an Aufgaben ist, die erstmal nicht umgesetzt werden, desto besser können Du und Dein Team sich auf die Dinge konzentrieren, die einen direkten Nutzen für die Anwender haben. 

Mit dem folgenden Prozess kannst Du entscheiden, welche User Stories vorerst nicht umgesetzt werden.

Schritt 1: Bewertung von Umfang, Aufwand und Nutzen

Der Umfang gibt an, was in der Story enthalten ist und was nicht. Die Abgrenzung des Umfangs hilft, den Aufwand besser zu schätzen.

Der Aufwand wird dann durch Schätztechniken wie „Planning Poker“ ermittelt, bei denen Teammitglieder Schätzungen für die Fertigstellung einer Story abgeben. Als Maßeinheit werden in der Regel Story Points oder Idealstunden verwendet.

Der Nutzen ergibt sich durch Gespräche mit Stakeholdern, Produktmanagern oder Kunden und beschreibt den Wert oder den Vorteil, den eine Story für den Endbenutzer oder das Unternehmen bringt. Die goldene Regel lautet: kein Nutzen = keine Story. 

Schritt 2: Priorisierung anhand von Priorisierungstechniken

Ausgehend von der Bewertung einzelner Dimensionen in Schritt eins, können User Stories priorisiert werden. 

Mögliche Priorisierungstechniken dafür sind …

• MoSCoW: Steht für Must Have, Should Have, Could Have und Won’t Have. Dabei werden Anforderungen in diese Kategorien eingeteilt.
• Kano-Modell: Teilt Features in Basismerkmale, Leistungsmerkmale und Begeisterungsmerkmale ein.
• Value vs. Effort: Eine Matrix, bei der die Stories basierend auf ihrem geschätzten Wert (Nutzen) und ihrem geschätzten Aufwand (Kosten) platziert werden.

Schritt 3: Umsetzung in Sprints mit Story Cards

Die User Story, dazugehörige Akzeptanzkriterien sowie Priorisierung und Aufwandsschätzung werden auf Story Cards dokumentiert. Story Cards sind physische oder digitale Karten und dienen als ständige Erinnerung und Referenz für das Team während des Sprints.

Bei der Sprint-Planung werden hoch priorisierte Stories aus dem Product Backlog in den Sprint Backlog übernommen – basierend auf der Gesamtkapazität des Teams und der Summe der Story Points der ausgewählten Stories.

Während des Sprints arbeitet das Team an der Umsetzung der ausgewählten User Stories. Die Fortschritte werden häufig in einer Projektmanagement-Software auf einem Scrum-Board oder Kanban-Board dargestellt, auf dem die Story Cards durch verschiedene Status (z. B. „To Do“, „In Arbeit“, „Abgeschlossen“) bewegt werden.

Vorlage für den Aufbau einer Story Card: 

Am Ende des Sprints sollte jede User Story entweder vollständig umgesetzt (und den Akzeptanzkriterien entsprechend getestet) oder, falls sie nicht fertig wurde, in den Product Backlog zurückversetzt werden, um in einem zukünftigen Sprint erneut betrachtet zu werden.

Durch die richtige Priorisierung und die Verwendung von Story Cards in Sprints kann ein agiles Team sicherstellen, dass es immer an den hilfreichsten und relevantesten Features arbeitet und dabei einen kontinuierlichen Mehrwert für den Endbenutzer liefert.

Fazit 

In der agilen Produktentwicklung stehen Individuen über Tools und die Entwicklung von funktionierender Software mit direktem Mehrwert für den Endnutzer an erster Stelle. Und genau das spiegelt sich im Konzept der User Story wider. Aus Nutzerperspektive formuliert und immer mit einem konkreten Nutzen im Sinn sind User Stories nicht nur Anforderungen, sondern auch Gesprächsanlässe, die zu einem tieferen Verständnis für den Endnutzer führen. 

Sie sind die kleinste Einheit in agilen Entwicklungsprozessen und – bevor sie es in den Product Backlog schaffen – erstmal Ansätze für Diskussionen zwischen Product Owner, Entwicklern und anderen Stakeholdern. Mit einem klaren Verständnis von Aufbau, Erstellung, Akzeptanzkriterien und Bewertung von User Stories können Teams effektiv und effizient Softwarelösungen liefern, die den Bedürfnissen der Benutzer gerecht werden.

FAQs

Was ist eine User Story?

Eine User Story ist eine kurze, einfache Beschreibung einer Softwareanforderung aus der Perspektive des Endbenutzers. Sie hilft Entwicklern und Projektbeteiligten zu verstehen, was der Benutzer von einer Software oder einem Feature erwartet.

Wie formuliert man User Stories?

User Stories werden oft mit der Struktur „Als [Rolle] möchte ich [Aktion/Wunsch], damit [Nutzen/Ziel]“ formuliert. Dies gibt einen klaren Kontext über die Rolle des Benutzers, was er erreichen möchte und warum.

Was ist der Unterschied zwischen Use Case und User Story?

Ein Use Case beschreibt detailliert, wie ein System auf die Aktionen eines Benutzers reagieren soll, oft in Form von Interaktionsszenarien. Eine User Story hingegen ist eine kurze, informelle Beschreibung einer Funktion aus der Sicht des Benutzers und ohne detaillierte Abläufe.

Was ist User Story Mapping?

User Story Mapping ist eine Methode zur Anordnung und Priorisierung von User Storys. Dabei werden die Geschichten in der Reihenfolge ihrer Umsetzung oder ihrer Bedeutung für den Benutzer auf einer visuellen Karte angeordnet. Dies hilft Teams, den Überblick über komplexe Projekte zu behalten und den Entwicklungsfortschritt zu verfolgen.