Beispiele für User Stories: 16 kommentierte Beispiele – gute und schlechte

Sechzehn kommentierte Beispiele für User Stories aus den Bereichen Authentifizierung, E-Commerce, Mobile, APIs und Fehlerbehebung, wobei die fehlerhaften Versionen neben den überarbeiteten Fassungen dargestellt sind, sodass der Unterschied deutlich erkennbar ist.

Sechzehn Beispiele für User Stories, die aus den Bereichen stammen, in denen Teams tatsächlich arbeiten: Authentifizierung, E-Commerce, Mobile, APIs, Fehlerbehebung und interne Tools. Jedes Beispiel ist mit Anmerkungen versehen: Es wird nicht nur erläutert, was die Story aussagt, sondern auch, warum die Rollen- und Nutzenklauseln ihren Wert haben. Vier davon sind bewusst schlecht formuliert und werden neben ihren überarbeiteten Fassungen gezeigt, denn der schnellste Weg, das Format zu erlernen, besteht darin, zu beobachten, wie es scheitert.

Sollte Ihnen das Format selbst noch neu sein, beginnen Sie mit Was ist eine User Story?. Kurz gesagt folgt jede Story hier dem Schema „Als [Rolle] möchte ich [Ziel], damit [Vorteil]“, und jede gute Story könnte direkt in die Verfeinerung und eine Runde Planning Poker übergehen.

Authentifizierung und Konten

1. Anmeldung

Als Stammkunde möchte ich mich mit meiner E-Mail-Adresse und meinem Passwort anmelden, damit ich meine Bestellhistorie einsehen kann.

Warum dies funktioniert: Die Rolle ist konkret definiert. „Stammkunde“ vermittelt Ihnen, dass diese Person über ein Konto verfügt, bereits bestellt hat und einen Grund hat, wiederzukommen: drei Fakten, die ein Designer und ein Tester nutzen können. „Als Nutzer“ hätte keinen dieser Aspekte vermittelt.

2. Passwort zurücksetzen

Als Nutzer, der sich nicht mehr einloggen kann, möchte ich mein Passwort über den Anmeldebildschirm zurücksetzen, damit ich wieder Zugriff auf mein Konto erhalte, ohne den Support kontaktieren zu müssen.

Warum dies funktioniert: In der Leistungsbeschreibung wird ein konkreter Kostenfaktor genannt. Jedes Zurücksetzen, das über den Support abgewickelt wird, ist messbarer finanzieller Aufwand; daher kann dieser Fall im Vergleich zu anderen auf der Grundlage von Fakten und nicht aufgrund von Vermutungen priorisiert werden. Beachten Sie, was der Satz nicht beinhaltet: das Ablaufen von Token, Ratenbegrenzungen und die E-Mail-Vorlage. Diese Details gehören in die Akzeptanzkriterien, die verfasst werden, wenn das Team den Fall verfeinert:

  • Innerhalb von zwei Minuten nach der Anfrage erhalten Sie eine E-Mail zum Zurücksetzen.
  • Der Link zum Zurücksetzen läuft nach einer Stunde ab und kann nur einmal verwendet werden.
  • Das Formular liefert dieselbe Antwort, unabhängig davon, ob die E-Mail-Adresse existiert oder nicht (keine Kontenaufzählung).

3. Die zirkuläre Erzählung

Als Benutzer möchte ich mich anmelden, damit ich auf die App zugreifen kann.

Warum dies nicht funktioniert: Jeder Platzhalter ist ausgefüllt, und es wird nichts gesagt. Die Rolle bezieht sich auf „niemand Bestimmtes“, und der Nutzen wiederholt lediglich das Ziel, sodass der „damit“-Satz gestrichen werden könnte, ohne dass Informationen verloren gingen. Eine Geschichte wie diese besteht zwar die Formatprüfung, umgeht jedoch all das Nachdenken, zu dem das Format eigentlich anregen soll.

Die überarbeitete Fassung:

Als Projektmitglied, das mitten im Sprint zurückkehrt, möchte ich nach der Anmeldung direkt auf dem Board landen, das ich zuletzt angesehen habe, damit ich nicht jeden Morgen erneut dorthin navigieren muss.

Nun gibt es also eine Person, einen Moment und einen Vorteil, den jemand gegen andere Arbeit abwägen könnte.

E-Commerce

4. Speicherung des Warenkorbs

Als Kunde, der in seiner Mittagspause im Internet stöbert, möchte ich, dass die Artikel in meinem Warenkorb erhalten bleiben, wenn ich heute Abend zurückkomme, damit ich nicht alles erneut suchen muss.

Warum dies funktioniert: Die Rolle enthält ein Szenario. „In der Mittagspause stöbern“ erklärt, warum Warenkörbe mitten im Kaufprozess zurückgelassen werden, was dem Team verdeutlicht, dass das entscheidende Zeitfenster hier Stunden und nicht Sekunden beträgt. Eine gut gewählte Rolle bringt den Kontext in einem einzigen Satz zum Ausdruck.

5. Gast-Kasse

Als Erstkäufer möchte ich zur Kasse gehen, ohne ein Konto anzulegen, damit ich meinen Einkauf abschließen kann, bevor ich es mir anders überlege.

Warum dies funktioniert: Es wird eine Produktposition eingenommen (Konten sind optional) und der tatsächliche Nutzen dargelegt: Zögern verhindert Erstkäufe. So klare Darstellungen decken Meinungsverschiedenheiten zudem frühzeitig auf: Wenn das Unternehmen möchte, dass jeder Käufer ein Konto hat, findet diese Auseinandersetzung in der Weiterentwicklung statt – nicht im Pull-Request.

6. Die Figur in einem Kostüm aus der Geschichte

Als Kunde wünsche ich mir einen schnelleren und übersichtlicheren Bezahlvorgang, damit sich die Konversionsrate verbessert.

Warum dies nicht funktioniert: aus zwei Gründen. „Schneller, sauberer“ ist keine Funktion, die irgendjemand entwickeln oder testen kann, und „die Konversionsrate verbessert sich“ ist der Vorteil für das Unternehmen, nicht für den Kunden. Kein Kunde wünscht sich eine Konversion. Hier wurde die Arbeit eines ganzen Quartals in einen Satz zusammengepresst, was daraus ein Epos macht, keine Geschichte.

Die Überarbeitung (ein Ausschnitt daraus):

Als Käufer, der über sein Smartphone einkauft, möchte ich, dass meine Lieferadresse anhand meiner Postleitzahl automatisch ausgefüllt wird, damit ich den Bestellvorgang mit einer Hand abschließen kann.

Das große Projekt zerfällt in eine Reihe solcher Teilabschnitte, von denen jeder einzeln getestet werden kann und klein genug ist, um ihn zu bewältigen.

Mobil

7. Offline-Modus

Als Außendiensttechniker möchte ich, dass der heutige Arbeitsauftrag auch ohne Internetverbindung geladen wird, damit ich auch in Kellern und in Funklöchern weiterarbeiten kann.

Warum es funktioniert: Die Rolle bestimmt die Anforderung. Die Mitarbeiter im Büro nehmen den Offline-Support gar nicht wahr; die Außendiensttechniker sind täglich damit konfrontiert. Wenn jemand bei der Präzisierung fragt: „Wie offline ist offline?“, hat die Rolle die Antwort bereits gegeben: überall dort, wohin der Auftrag sie führt.

8. Benachrichtigungseinstellungen

Als Abonnent, der täglich drei Push-Benachrichtigungen erhält, möchte ich selbst entscheiden, bei welchen Benachrichtigungstypen ich Benachrichtigungen erhalten möchte, damit ich nicht mehr die gesamte App stumm schalten muss.

Warum dies funktioniert: Der Nutzen benennt den Fehlerfall, den die Story verhindert. Nutzer beschweren sich nicht über die Anzahl der Benachrichtigungen; sie schalten die App stumm und verlassen sie stillschweigend. Eine Story, die das stillschweigende Verhalten benennt, gegen das sie sich wendet, ist eine Story, über die das Team ehrlich diskutieren kann.

APIs und technische Arbeiten

9. Paginierung

Als Integrationsentwickler wünsche ich mir paginierte Antworten am Endpunkt „/events“, damit es bei großen Konten bei meiner nächtlichen Synchronisierung nicht zu einer Zeitüberschreitung kommt.

Warum dies funktioniert: Dies ist die legitime technische User Story: Der Entwickler ist ein echter, externer Nutzer mit eigenen Zielen, nicht das Team, das sich selbst in den Satz einfügt. API-Nutzer, Plugin-Autoren und Bereitschaftsdienstmitarbeiter erfüllen alle diese Voraussetzung.

10. Ratenbegrenzung

Als API-Nutzer wünsche ich mir eine 429-Antwort mit einem „Retry-After“-Header, wenn ich das Ratenlimit erreiche, damit mein Client eine Pause einlegen kann, anstatt den gesamten Vorgang abzubrechen.

Warum dies funktioniert: Das Ziel ist präzise genug, um selbst als erstes Akzeptanzkriterium zu dienen, und es handelt sich nach wie vor um ein Was und nicht um ein Wie: Hier wird die Umsetzung des Begrenzers in keiner Weise vorgegeben.

11. Die getarnte Umgestaltung

Als Entwickler möchte ich das Zahlungsmodul umgestalten, damit der Code übersichtlicher wird.

Warum dies nicht funktioniert: Die Rolle ist das Team, das Ziel ist eher eine Aktivität als ein Ergebnis, und „sauberer“ lässt sich nicht überprüfen. Hierbei handelt es sich um das Story-Format, das auf eine Aufgabe angewendet wird, für die es nicht konzipiert wurde – ein Fall, der in Wenn User Stories das falsche Werkzeug sind behandelt wird.

Die Überarbeitung (absichtlich keine User Story):

Reduzieren Sie die Anbieterkopplung des Zahlungsmoduls, sodass ein neuer Zahlungsanbieter hinzugefügt werden kann, ohne den Kern des Bezahlvorgangs zu verändern. Als abgeschlossen gilt: Die Anbieterschnittstelle ist extrahiert, die beiden bestehenden Anbieter laufen dahinter, und die Integrationstestsuite wird unverändert bestanden.

Ein schlichtes technisches Element mit einem klar definierten Ergebnis ist einer Geschichte mit ausgefallenen Kostümen stets überlegen.

Fehler oder Feature?

12. Der Fehler, der eine Geschichte ist

Als Kunde mit einem Jahresabonnement möchte ich, dass auf meiner Rechnung der mir angebotene Rabatt ausgewiesen wird, damit die Finanzabteilung den Betrag ohne Supportanfrage abgleichen kann.

Warum dies funktioniert: Die Ursache ist bekannt und der Umfang der Behebung ist klar definiert, sodass sich diese Aufgabe wie jede andere Story verhält: Sie erhält Kriterien, einen Umfang und einen Platz im Sprint. Die Zuordnung von Fehlerbehebungen sorgt dafür, dass die Velocity ein realistisches Bild davon vermittelt, wohin die Kapazität tatsächlich fließt; im Kapitel über Story-Punkte wird dieses Argument ausführlich dargelegt.

13. Der Fehler, der keiner ist

Kunden berichten gelegentlich, dass ihnen der Betrag doppelt in Rechnung gestellt wurde. Eine zuverlässige Reproduktion des Problems ist nicht möglich.

Warum dies keine Story ist: Es gibt keinen Spielraum für Versprechungen. Ein „Rolle-Ziel-Nutzen“-Satz („Als Kunde möchte ich nicht doppelt belastet werden…“) wäre zwar wahr, aber nutzlos, und jede Schätzung würde lediglich Hoffnungen widerspiegeln. Der richtige Ansatz ist ein zeitlich begrenzter Spike: Zwei Tage lang untersuchen, die gewonnenen Erkenntnisse präsentieren und anschließend die eigentliche Story für die Behebung des Problems verfassen.

Interne Tools und Berichterstattung

14. Hilfswerkzeuge

Als Support-Mitarbeiter im Live-Chat möchte ich die letzten fünf Anmeldeversuche des Kunden einsehen können, damit ich auf einen Blick unterscheiden kann, ob es sich um ein vergessenes Passwort oder um ein gesperrtes Konto handelt.

Warum es funktioniert: Interne Nutzer sind immer noch Nutzer. Der Nutzen wird in Sekunden pro Ticket gemessen – und genau diese konkrete Kennzahl sorgt dafür, dass dieses Projekt bei der Vergabe von Sprint-Plätzen mit kundenorientierten Aufgaben konkurrieren kann, anstatt von vornherein den Kürzeren zu ziehen.

15. Exporte

Als Teamleiter möchte ich den Sprint-Bericht als CSV-Datei exportieren, damit ich die Ergebnisse an Beteiligte weitergeben kann, die über kein Konto verfügen.

Warum dies funktioniert: Der „damit“-Satz grenzt den Aufgabenbereich unauffällig ein. Die Weitergabe außerhalb des Tools ist die Aufgabe, was Lösungen wie in-App-Dashboards und Regeln im langweiligen, portablen CSV-Format ausschließt. Ein guter Nutzen-Satz leistet kostenlos Designarbeit.

16. Das Epos der Sichtbarkeit

Als Führungskraft wünsche ich mir eine Übersicht über alle Aktivitäten des Teams, damit ich den Überblick behalte.

Warum dies nicht funktioniert: „Alles“ ist kein Umfang und „Sichtbarkeit“ ist kein Ergebnis: Hier lässt sich nichts entwickeln, testen oder bemessen. Hinter einer solchen Story verbirgt sich eine echte Frage, die dem Manager bisher noch nicht gestellt wurde.

Die überarbeitete Fassung:

Als Delivery Manager, der die Statusbesprechung am Montag vorbereitet, möchte ich die Sprintziele der einzelnen Teams sowie deren Status (rot/gelb/grün) auf einer Seite zusammengefasst haben, damit ich blockierte Aufgaben kennzeichnen kann, ohne jeden Teamleiter einzeln anschreiben zu müssen.

Dieselbe Person, derselbe Instinkt, doch nun passt es in einen Sprint, und ein Tester weiß, wann es fertig ist.

Was die Guten gemeinsam haben

Werfen Sie einen Blick auf die zwölf, die funktionieren. Jedes nennt eine Person, die konkret genug ist, um eine Meinung zu haben, nennt ein Ziel, das diese Person erkennen würde, und bietet einen Nutzen, der einer ehrlichen „Warum?“-Frage standhält. Keines davon enthält eine Umsetzung, und keines versucht, vollständig zu sein. Dafür sind Akzeptanzkriterien und das Verfeinerungsgespräch da.

Die „schlechten Vier“ scheitern auf genau zwei Arten, was ermutigend ist: Entweder ist der Nutzen zirkulär (niemand hat geprüft, warum) oder der Umfang ist ein „Epic“ (niemand hat geprüft, wie groß). Beide Fehler treten in dem Moment zutage, in dem Ihr Team versucht, die Story einzuschätzen. Deshalb erkennen Sizing-Sitzungen schlechte Stories schneller als jede Richtlinie zum Verfassen von Stories: Eine große Streuung bei der Abstimmung ist die Fehlermeldung dieses Formats. Verfassen Sie Ihre nächste Reihe anhand der Vorlage, legen Sie diese dann dem Team mit Planning Poker vor und beobachten Sie, welche davon zu einer Einigung führen.

Häufig gestellte Fragen

Was ist ein Beispiel für eine User Story?

„Als Stammkunde möchte ich mich mit meiner E-Mail-Adresse und meinem Passwort anmelden, damit ich meine Bestellhistorie einsehen kann.“ Darin werden eine bestimmte Person, eine Fähigkeit aus Sicht dieser Person und der Grund genannt, warum es sich lohnt, diese Arbeit einzuplanen. Diese dreiteilige Struktur (Rolle, Ziel, Nutzen) entspricht dem klassischen Format einer User Story.

Wie verfasst man eine gute User Story?

Nennen Sie eine konkrete Rolle anstelle von „ein Benutzer“, formulieren Sie das Ziel als eine Handlung der Person und nicht als etwas, das das System enthält, und schließen Sie den „damit“-Satz mit einem Nutzen ab, der einem ehrlichen „Warum?“ standhalten würde. Fügen Sie anschließend Akzeptanzkriterien hinzu, denn der Satz der Story dient als Gesprächsaufhänger und nicht als Anforderung.

Kann technische Arbeit als User Story formuliert werden?

Manchmal. Wenn es sich bei dem „Benutzer“ um eine reale Person handelt (einen Integrationsentwickler, der Ihre API nutzt, oder einen Bereitschaftsdienstmitarbeiter), funktioniert das Format wie beschrieben. Wenn die einzig sinnvolle Rolle „das Team“ ist, verzichten Sie auf die „Verkleidung“ und verfassen Sie einen schlichten technischen Punkt mit einem benannten Ergebnis und Akzeptanzkriterien. Die Disziplin bleibt erhalten; die Satzstruktur muss es nicht.

Sollten Fehler als User Stories formuliert werden?

Ein Fehler mit bekannter Ursache und einer eindeutigen Behebung ist möglich, und dessen Erfassung sorgt für eine realistische Einschätzung der Velocity. Ein Fehler, den niemand reproduzieren kann, ist dies nicht: Es gibt keinen Spielraum für Versprechungen, sodass eine Story lediglich eine Vermutung mit einer Nutzenklausel wäre. Legen Sie zunächst einen Zeitrahmen für die Untersuchung fest und verfassen Sie anschließend die eigentliche Story auf der Grundlage der dabei gewonnenen Erkenntnisse.

Wie detailliert sollte eine User Story sein?

Ein Satz, der die Geschichte beschreibt, gefolgt von drei bis fünf Akzeptanzkriterien. Der Satz bildet den Ausgangspunkt für die Diskussion; die Kriterien fassen das Ergebnis dieser Diskussion zusammen. Sollte die Liste der Kriterien über fünf hinauswachsen, handelt es sich bei der Geschichte um mehrere Geschichten, und die Kriterien zeigen Ihnen, an welcher Stelle Sie sie aufteilen sollten.

Weiterführende Literatur