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

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 geht nicht nur darum, was die Story aussagt, sondern auch darum, 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 der Frage: „Was ist eine User Story?“ Kurz gesagt folgt jede Story hier dem Schema „Als [Rolle] möchte ich [Ziel], damit [Nutzen]“, 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“ besagt, 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 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 Vermutungen priorisiert werden. Beachten Sie, was der Satz nicht beinhaltet: 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 gibt unabhängig davon, ob die E-Mail-Adresse existiert oder nicht, dieselbe Antwort zurück (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 niemanden Bestimmten, 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 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 verlassen 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 Auseinandersetzung in der Weiterentwicklung geführt, 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 wurde die Arbeit eines ganzen Quartals in einen Satz komprimiert, was daraus eher ein Epos als eine Geschichte macht.

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 getestet werden kann 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 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, wo der Auftrag sie hinführt.

8. Benachrichtigungseinstellungen

Als Abonnent, der täglich drei Push-Benachrichtigungen erhält, möchte ich selbst bestimmen, 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 einem Timeout kommt.

Warum dies funktioniert: Dies ist die legitime technische User Story: Der Entwickler ist ein echter, externer Nutzer mit eigenen Zielen und 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 möchte ich eine 429-Antwort mit einem „Retry-After“-Header erhalten, 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, 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. Hier wird das Story-Format auf eine Aufgabe angewendet, für die es nicht konzipiert wurde – ein Fall, der im Artikel „Wann User Stories das falsche Werkzeug sind“ behandelt wird.

Die Überarbeitung (absichtlich keine User Story):

Reduzieren Sie die Anbieterabhängigkeit 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 konkret benannten 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 Buchhaltung die Abrechnung ohne Supportanfrage vornehmen 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 Erfassung von Fehlerbehebungen sorgt dafür, dass die Velocity realistisch widerspiegelt, 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 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 erkennen 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 im Wettbewerb um einen Sprint-Platz mit kundenorientierten Aufgaben mithalten 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 eigentliche Aufgabe, was Lösungen wie In-App-Dashboards und Regeln im langweiligen, portablen CSV-Format ausschließt. Ein gut formulierter Zweckabsatz übernimmt die Designarbeit quasi kostenlos.

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 zurück auf die zwölf, die funktionieren. Jedes nennt eine Person, die konkret genug ist, um eine Meinung zu haben, formuliert ein Ziel, das diese Person wiedererkennen würde, und beinhaltet einen Nutzen, der einem ehrlichen „Warum?“ standhält. Keines davon enthält eine konkrete Umsetzung, und keines versucht, vollständig zu sein. Dafür sind die 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 decken Sizing-Sitzungen schlechte Stories schneller auf 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 von Stories anhand der Vorlage, legen Sie sie dann dem Team im Rahmen 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 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 einzige sinnvolle Rolle „das Team“ ist, lassen Sie die Rolle beiseite 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 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: Da es keinen Rahmen für eine Zusage gibt, wäre eine Story lediglich eine Vermutung mit einer Nutzenklausel. 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 zusammen, was in der Diskussion beschlossen wurde. 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

• Agile Schätzung: Der umfassende Leitfaden. Hier finden Sie alles zum Thema.
• Was ist eine User Story? Das Format, die drei Cs und die INVEST-Checkliste, die jedem der oben genannten Beispiele zugrunde liegen.
• Vorlage für User Stories und Akzeptanzkriterien. Eine Vorlage zum Kopieren und Einfügen sowie ein ausgearbeitetes Beispiel bis hin zur Schätzung.
• Aufteilung von User Stories. Wie geht man mit den Epics um, die sich in den Beispielen 6 und 16 verbergen?
• Beispiele für agile Schätzungen. Die begleitende Serie: Wie die Einstufung dieser Stories im Team tatsächlich klingt.