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

Sechzehn Beispiele für User Stories aus den Bereichen Authentifizierung, E-Commerce, Mobile, APIs und Fehlerbehebung – jedes davon mit Anmerkungen versehen, wobei die fehlerhaften Versionen neben den überarbeiteten Fassungen dargestellt sind, sodass der Unterschied deutlich wird.

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 Erläuterungen versehen – nicht nur dazu, 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 Versionen gezeigt, denn der schnellste Weg, das Format zu erlernen, besteht darin, zu beobachten, wie es fehlschlägt.

Falls Ihnen das Format selbst noch neu ist, beginnen Sie mit Was ist eine User Story? – kurz gesagt folgt jede Story hier dem Muster „Als [Rolle] möchte ich [Ziel], damit [Nutzen]“ und jede gute User Story könnte direkt in die Verfeinerung und eine Runde Planning Poker einfließen.

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 zuvor 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 zum Ausdruck gebracht.

2. Passwort zurücksetzen

Als Nutzer, der sich nicht mehr anmelden 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 Vorteilsbeschreibung wird ein konkreter Kostenfaktor genannt. Jedes Reset, das über den Support abgewickelt wird, ist messbarer Geldaufwand; daher kann dieser Fall gegenüber anderen auf der Grundlage von Fakten und nicht aufgrund von Eindrücken priorisiert werden. Beachten Sie, was der Satz nicht enthält – das Ablaufen von Token, Ratenbegrenzungen, die E-Mail-Vorlage. Diese Details gehören in die Akzeptanzkriterien, die verfasst werden, wenn das Team diese 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 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 Nutzer möchte ich mich anmelden, damit ich auf die App zugreifen kann.

Warum dies nicht funktioniert: Jeder Platzhalter ist ausgefüllt, doch es wird nichts gesagt. Die Rolle ist „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, lässt jedoch all das Nachdenken außer Acht, zu dem das Format eigentlich anregen soll.

Die überarbeitete Fassung:

Als Projektmitglied, das mitten im Sprint zurückkehrt, möchte ich nach dem Einloggen 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 es 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, wird diese Frage im Rahmen der Weiterentwicklung geklärt, nicht im Pull-Request.

6. Die Figur in einem Kostüm aus einer 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 jeder entwickeln oder testen kann, und „die Konversionsrate verbessert sich“ ist der Vorteil für das Unternehmen, nicht für den Käufer – kein Käufer wünscht sich eine Konversion. Hier wird die Arbeit eines ganzen Quartals in einen Satz komprimiert, 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 epische Projekt zerfällt in eine Reihe solcher Teilabschnitte, von denen jeder einzeln testbar und klein genug ist, um ihn zu bewältigen.

Mobil

7. Offline-Modus

Als Außendiensttechniker möchte ich, dass der Arbeitsauftrag für heute 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 Verfeinerung fragt: „Wie offline ist offline?“, hat die Rolle diese Frage bereits beantwortet – wo auch immer der Auftrag sie hinführt.

8. Benachrichtigungseinstellungen

Als Abonnent, der täglich drei Push-Benachrichtigungen erhält, möchte ich selbst festlegen, für welche 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 dabei 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 überarbeiten, 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. Hier wird das Story-Format auf eine Aufgabe angewendet, 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 Anbieterbindung 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 kostümierten Geschichte 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 Buchhaltung die Abrechnung ohne Supportanfrage vornehmen kann.

Warum dies funktioniert: Die Ursache ist bekannt und der Umfang der Behebung ist klar definiert, sodass sich dies 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; das Kapitel über Story-Punkte erläutert dieses Argument ausführlich.

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 Schritt 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 – genau diese Art von konkretem Nutzen sorgt dafür, dass diese Aufgabe 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 definiert stillschweigend den Umfang der Arbeit. Das Teilen 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 übernimmt die Designarbeit kostenlos.

16. Das Epos der Sichtbarkeit

Als Führungskraft möchte ich einen Überblick über alle Aktivitäten des Teams haben, damit ich den Überblick behalte.

Warum dies nicht funktioniert: „Alles“ ist kein Anwendungsbereich 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 zurück 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 wiedererkennen würde, und bietet einen Nutzen, der einem ehrlichen „Warum?“ 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 mithilfe von Planning Poker vor und beobachten Sie, bei welchen sich die Einschätzungen annähern.

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.“ Hier werden eine bestimmte Person, eine Fähigkeit aus deren Sicht sowie der Grund genannt, warum es sich lohnt, diese Aufgabe zu planen. 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 stellt keine Anforderung dar.

Kann technische Arbeit als User Story formuliert werden?

Manchmal. Wenn der „Benutzer“ real ist – ein Integrationsentwickler, der Ihre API nutzt, oder ein Bereitschaftsdienstmitarbeiter –, funktioniert das Format wie beschrieben. Wenn die einzige sinnvolle Rolle „das Team“ ist, lassen Sie die Verkleidung weg und verfassen Sie einen einfachen technischen Punkt mit einem benannten Ergebnis und Akzeptanzkriterien. Die Disziplin bleibt erhalten; die Satzstruktur muss sich nicht ändern.

Sollten Fehler als User Stories formuliert werden?

Ein Fehler, dessen Ursache bekannt ist und für den es eine eindeutige Lösung gibt, kann dies sein, und dessen Nennung sorgt für eine realistische Einschätzung der Velocity. Ein Fehler, den niemand reproduzieren kann, kann 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 dann 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. Wenn die Liste der Kriterien über fünf hinauswächst, handelt es sich bei der Geschichte um mehrere Geschichten, und die Kriterien zeigen Ihnen, wo Sie sie aufteilen sollten.

Weiterführende Literatur