# User Stories schreiben: Vorlage, Beispiele, Kriterien

> Eine User Story schreibst du nach dem Muster „Als [Rolle] möchte ich [Ziel], damit [Nutzen]“ und ergänzt sie um drei bis sieben Akzeptanzkriterien, die ein Tester abhaken kann. Gute Stories erfüllen die INVEST-Kriterien: unabhängig, verhandelbar, wertvoll, schätzbar, klein und testbar. Zu große Stories zerlegst du entlang von Arbeitsschritten, Regeln oder Datenvarianten.

- URL: https://go-projects.de/projektplanung/user-stories-schreiben/
- Sprache: de
- Aktualisiert: 2026-10-19
- Herausgeber: Go Projects (OnlineBuilders LLC, https://onlinebuilders.biz)

Die meisten schlechten User Stories sind keine Stories, sondern verkleidete Aufgaben. „Als Entwickler möchte ich die Datenbank migrieren“ hat zwar die richtige Form, aber keinen Nutzer und keinen Nutzen. Das Team weiß danach, was es tun soll. Es weiß nicht, wofür.

Das Format selbst ist überraschend jung. Laut Agile Alliance entstand die Satzschablone „Als … möchte ich … damit …“ im Jahr 2001 bei der britischen Firma Connextra. Im selben Jahr beschrieb Ron Jeffries, einer der Väter von Extreme Programming, die drei Bestandteile einer Story: die Karte, das Gespräch und die Bestätigung. Die Karte ist nur der Merkzettel. Die eigentliche Anforderung entsteht im Gespräch und wird durch Akzeptanztests bestätigt.

Diesen Teil vergessen viele Teams.

## Die Vorlage: drei Teile, nicht einer

Eine vollständige User Story hat drei Bausteine.

1. Die Story selbst: „Als [Rolle] möchte ich [Ziel], damit [Nutzen].“
2. Akzeptanzkriterien: prüfbare Bedingungen, wann die Story erfüllt ist.
3. Notizen aus dem Gespräch: Annahmen, Skizzen, offene Fragen, Links.

Ein Beispiel aus einem Kundenportal für einen Energieversorger:

> Als Kundin mit Abschlagszahlung möchte ich meinen monatlichen Abschlag online anpassen, damit ich nach einer Preiserhöhung keine hohe Nachzahlung bekomme.

Akzeptanzkriterien dazu:

- Die Kundin sieht ihren aktuellen Abschlag und den vom System empfohlenen Betrag.
- Sie kann einen Betrag zwischen 50 % und 200 % des empfohlenen Werts eintragen.
- Unter dem Mindestwert erscheint ein Hinweis mit Begründung, Speichern ist nicht möglich.
- Die Änderung gilt ab dem übernächsten Abbuchungstermin, das Datum wird angezeigt.
- Sie erhält eine Bestätigung per E-Mail innerhalb von fünf Minuten.

Fünf Kriterien, jedes mit Ja oder Nein prüfbar. Ein Tester braucht dafür keine Rückfrage.

## Akzeptanzkriterien im Gegeben-Wenn-Dann-Format

Für Regeln mit Bedingungen hat sich das Format aus dem Behaviour-Driven Development bewährt, im Original Given, When, Then. Auf Deutsch:

| Gegeben | Wenn | Dann |
|---|---|---|
| der empfohlene Abschlag beträgt 120 € | die Kundin 50 € einträgt | erscheint „Mindestens 60 € möglich“ und Speichern ist gesperrt |
| der empfohlene Abschlag beträgt 120 € | die Kundin 150 € einträgt | wird der Betrag gespeichert und das Gültigkeitsdatum angezeigt |
| die Kundin hat einen offenen Mahnvorgang | sie die Seite öffnet | ist die Anpassung deaktiviert und ein Kontakthinweis sichtbar |

Der Vorteil: Jede Zeile ist zugleich ein Testfall. Teams, die automatisiert testen, können solche Tabellen fast direkt in Testcode übersetzen.

## Der INVEST-Check

Bill Wake hat 2003 sechs Kriterien für gute Stories zusammengefasst. Mike Cohn hat sie ein Jahr später in seinem Buch „User Stories Applied“ bekannt gemacht. Die Liste taugt als Prüfung, bevor eine Story in die Planung geht.

**INVEST: sechs Fragen an jede User Story**

- [ ] **Independent:** Lässt sie sich ohne eine andere Story umsetzen und ausliefern?
- [ ] **Negotiable:** Ist das Wie noch offen, oder steht schon eine Lösung drin?
- [ ] **Valuable:** Hat ein Nutzer oder der Auftraggeber etwas davon, wenn nur diese Story fertig ist?
- [ ] **Estimable:** Kann das Team den Aufwand grob schätzen?
- [ ] **Small:** Passt sie in einen Sprint, besser in zwei bis drei Arbeitstage?
- [ ] **Testable:** Gibt es Akzeptanzkriterien, die man mit Ja oder Nein prüfen kann?

Das Kriterium „Independent“ ist in der Praxis am schwersten. Völlig unabhängige Stories gibt es selten. Es reicht, wenn die Reihenfolge flexibel bleibt.

## Große Stories zerlegen: vier Muster

Eine Story wie „Als Kunde möchte ich online bezahlen“ ist ein Epic. Sie passt in keinen Sprint. Vier Schnitte funktionieren fast immer:

- Nach Arbeitsschritten: erst „Rechnung als PDF ansehen“, dann „per Lastschrift bezahlen“, dann „Zahlungsbestätigung erhalten“.
- Nach Regeln: erst die Standardzahlung, später Sonderfälle wie Teilzahlung oder Gutschriften.
- Nach Datenvarianten: erst Lastschrift, dann Kreditkarte, dann weitere Zahlarten.
- Nach Qualität: erst eine einfache Version für 100 Nutzer, später Optimierung für 10.000.

Welcher Schnitt der richtige ist, entscheidet der Nutzen. Wenn 80 Prozent der Kunden per Lastschrift zahlen, ist die Lastschrift-Story allein schon ein brauchbares Release, und die Kreditkarte kann warten, bis jemand danach fragt.

Wichtig: Jeder Schnitt muss für sich einen Nutzen liefern. „Backend für Zahlung bauen“ und „Frontend für Zahlung bauen“ sind keine Stories, sondern technische Aufgaben. Wer horizontal nach Schichten schneidet, hat nach dem Sprint nichts, was ein Nutzer ausprobieren kann.

## Typische Fehler und wie sie aussehen

Manche Fehler erkennt man schon am ersten Satz.

| Schwach | Besser |
|---|---|
| Als Nutzer möchte ich mich einloggen. | Als Außendienstler möchte ich mich mit Fingerabdruck anmelden, damit ich beim Kunden nicht mein Passwort tippen muss. |
| Als Admin möchte ich ein Dashboard. | Als Teamleiterin möchte ich montags die offenen Tickets pro Person sehen, damit ich Arbeit umverteilen kann. |
| Als System möchte ich Daten synchronisieren. | Als Disponent möchte ich Auftragsänderungen aus dem ERP spätestens nach fünf Minuten sehen, damit ich keine veralteten Touren plane. |

Das Muster dahinter: Die Rolle ist so konkret wie möglich, das Ziel beschreibt eine Tätigkeit, und der Nutzen sagt, was ohne die Funktion schiefläuft. Der Nutzen-Teil ist der wichtigste. Er hilft später beim [Priorisieren nach MoSCoW](https://go-projects.de/projektplanung/moscow-priorisierung/), weil man sieht, was auf dem Spiel steht.

## Wie fein müssen Stories für die Schätzung sein?

Für die grobe Budgetplanung reichen Epics. Für die Sprintplanung braucht das Team Stories, die es mit [Story Points schätzen](https://go-projects.de/schaetzung-und-budget/story-points-schaetzen/) kann. Eine praktische Grenze: Wenn das Team bei einer Story zwischen 3 und 13 Punkten schwankt, ist sie noch zu unklar oder zu groß.

Stories ersetzen übrigens nicht alles. Antwortzeiten, Datenschutzvorgaben, Browserunterstützung und Schnittstellen lassen sich schlecht als „Als … möchte ich …“ formulieren. Sie gehören in ein kurzes Begleitdokument, das sich an der [Gliederung eines Lastenhefts](https://go-projects.de/projektplanung/lastenheft-software-vorlage/) orientieren kann, oder in die Definition of Done des Teams.

Wer ein Produkt mit einem externen Team baut, sollte die ersten zehn bis zwanzig Stories gemeinsam schreiben. Bei Studios wie [OnlineBuilders](https://onlinebuilders.biz/how-we-work) gehört so eine gemeinsame Klärung zum Projektstart, und sie spart später Diskussionen über die Abnahme.

## Vom Backlog zur Abnahme

Gute Akzeptanzkriterien zahlen sich am Ende aus. Wenn jede Story prüfbare Kriterien hat, ist die Abnahme eine Abarbeitung statt einer Verhandlung. Die Kriterien landen direkt im [Abnahmeprotokoll](https://go-projects.de/projektsteuerung/abnahme-software-abnahmeprotokoll/), und Streit darüber, was „fertig“ heißt, wird selten.

Nächster Schritt: Nimm die fünf wichtigsten Einträge aus deinem Backlog und prüf jeden gegen die INVEST-Liste. Fehlt der „damit“-Teil oder fehlen Akzeptanzkriterien, schreib sie heute nach, bevor das Team schätzt.

## Häufige Fragen

### Wer schreibt User Stories?

Verantwortlich ist meist der Product Owner. Schreiben kann sie jeder im Team, auch Fachleute aus dem Vertrieb oder Support. Entscheidend ist, dass vor der Umsetzung ein Gespräch zwischen Fachseite und Entwicklung stattfindet.

### Wie viele Akzeptanzkriterien braucht eine User Story?

Drei bis sieben sind ein guter Richtwert. Mehr als zehn sind meist ein Zeichen, dass die Story zu groß ist und zerlegt werden sollte.

### Was ist der Unterschied zwischen Epic und User Story?

Ein Epic ist eine Story, die zu groß für einen Sprint ist, etwa „Kunden können online bezahlen“. Es wird in mehrere User Stories zerlegt, die jeweils in wenigen Tagen umsetzbar sind.

### Ersetzen User Stories das Lastenheft?

Teilweise. Funktionale Anforderungen lassen sich gut als Stories abbilden. Nicht-funktionale Anforderungen, Rahmenbedingungen und Schnittstellen gehören besser in ein kurzes Begleitdokument oder in die Definition of Done.

Foto: Ragesoss, CC BY 3.0 (https://commons.wikimedia.org/wiki/File:Sticky_notes_on_the_wall_of_the_Wikimedia_Foundation_office,_2010-10-26.jpg)