User-Story-Vorlage mit Akzeptanzkriterien (kostenlos)

Eine User Story Vorlage erfüllt zwei Aufgaben. Sie stellt sicher, dass jede Story dieselben drei Fragen beantwortet (wer, was, warum), und gibt dem Team einen festen Ort, an dem festgehalten wird, wie man erkennt, dass die Story abgeschlossen ist. Diese Seite bietet beides: das Einzeilen-Story-Format, eine vollständige Karten-Vorlage, die Sie kopieren können, Akzeptanzkriterien in drei Formaten, eine Definition of Ready und Done sowie ausgearbeitete Beispiele.

Wenn Sie neu bei User Stories sind, beginnen Sie mit unserem Leitfaden zu wie man User Stories schreibt, und kehren Sie dann hierher zurück, um die Vorlage zu nutzen.

Die Einzeilen-Vorlage für User Stories

Die meisten Teams nutzen das Format, das 2001 vom Connextra-Team in London stammt und durch das Buch User Stories Applied von Mike Cohn populär wurde (seine Übersicht über User Stories ist eine gute Einführung):

Als [Nutzertyp] möchte ich [eine Aktion oder Fähigkeit], damit [ein Nutzen oder Ergebnis].

Jeder Teil hat eine spezifische Aufgabe:

• „Als“ benennt eine echte Art von Nutzer, wie z. B. einen Erstkaufenden, einen Kontoadministrator oder einen wiederkehrenden Patienten. „Als Nutzer“ sagt dem Team nichts. Wenn Sie Personas haben, verwenden Sie deren Namen.
• „Ich möchte“ beschreibt, was der Nutzer tut oder erhält, in seinen eigenen Worten. Es sollte die Lösung nicht beschreiben („ein Dropdown“, „ein Redis-Cache“); lassen Sie dem Team Raum, die beste Lösung zu finden.
• „Damit“ benennt den Wert. Dies ist der Teil, der am häufigsten weggelassen wird und der am wichtigsten ist: Er ermöglicht es dem Team, eine einfachere Option vorzuschlagen, die dasselbe Ergebnis liefert, und dem Product Owner, die Priorität zu bestimmen.

Denken Sie daran, dass der Satz nicht die Anforderung ist. Ron Jeffries beschrieb eine Story als drei Dinge: die Karte, das Gespräch und die Bestätigung (die 3 Cs). Eine Vorlage hilft bei der Karte und der Bestätigung (den Akzeptanzkriterien); nichts ersetzt das Gespräch.

Die vollständige User Story Karten-Vorlage

Der Einzeiler reicht für einen Sticky Note. In einem Backlog-Tool benötigen Sie in der Regel einige zusätzliche Felder, damit die Story priorisiert, geschätzt und getestet werden kann. Dies sind die Felder, die wir nützlich finden; entfernen Sie alle, die Ihr Team nie liest.

Halten Sie „Kontext und Notizen“ kurz: Wenn es zu einer Seite voller Spezifikationen wird, ist die Story wahrscheinlich ein Epic und muss aufgeteilt werden (unser Story-Mapping-Guide zeigt, wie).

Kopierfertiges User-Story-Template

Fügen Sie dies in das Beschreibungsfeld eines Jira- oder Linear-Tickets, einer Notion-Datenbankvorlage oder der Kopfzeile einer Tabelle ein. Ersetzen Sie den Text in eckigen Klammern und löschen Sie Zeilen, die Sie nicht verwenden.

• ID: [PROJEKT-000]
• Titel: [Verb + Objekt, z. B. „Rechnungen als CSV exportieren“]
• Story: Als [Benutzerart] möchte ich [Aktion oder Fähigkeit], damit [Nutzen].
• Kontext: [Warum dies jetzt wichtig ist; Link zu Forschung, Support-Tickets oder Metriken]
• Abnahmekriterien: [3 bis 7 überprüfbare Bedingungen, in Checklisten- oder Given/When/Then-Form]
• Nicht im Scope: [Was diese Story bewusst nicht abdeckt]
• Designs: [Link zum Frame oder Prototyp]
• Abhängigkeiten: [Andere Stories, Services oder Entscheidungen]
• Priorität: [Must / Should / Could oder Backlog-Rang]
• Schätzung: [Punkte oder Größe, vom Team ausgefüllt]
• Offene Fragen: [Alles, was vor Sprintstart beantwortet werden muss]

Die Zeile „Nicht im Scope“ spart Diskussionen: „Beinhaltet keine SMS-Zurücksetzung“ auf der Karte zu schreiben, ist besser, als in der Sprint-Review festzustellen, dass jemand davon ausgegangen war, es sei enthalten.

Was Abnahmekriterien sind und wer sie schreibt

Abnahmekriterien sind die Bedingungen, die eine Story erfüllen muss, um vom Product Owner akzeptiert zu werden. Sie beschreiben das beobachtbare Verhalten aus Sicht des Nutzers, nicht wie der Code funktioniert. Gute Kriterien sind:

• Überprüfbar: Jemand kann Ja oder Nein sagen, ohne interpretieren zu müssen. „Schnell“ ist nicht überprüfbar; „Ergebnisse erscheinen innerhalb von zwei Sekunden“ schon.
• Spezifisch für diese Story: Regeln, die für jede Story gelten (Code-Review, Deployment auf Staging), gehören in die Definition of Done, nicht hierher.
• Frei von Implementierungsdetails: Sagen Sie, was passiert, nicht welches Komponente oder welche Tabelle es bewirkt.
• Ehrlich im Fehlerfall: Mindestens ein Kriterium deckt ungültige Eingaben, fehlende Netzwerkverbindung oder fehlende Berechtigungen ab.
• Wenig: Drei bis sieben Kriterien sind ein gesunder Bereich. Mehr als zehn bedeutet in der Regel, dass die Story aufgeteilt werden sollte.

Der Product Owner ist für die Kriterien verantwortlich, sollte sie aber nicht allein schreiben. Das zuverlässigste Muster ist ein kurzes Refinement-Gespräch zwischen Produkt, einem Entwickler und einem Tester (oft als „Three Amigos“ bezeichnet): Was ist der Wert, wie wird dies gebaut, wie könnte es fehlschlagen.

Format 1: Abnahmekriterien als Checkliste

Eine einfache Liste von Bedingungen. Es ist das schnellste Format zum Schreiben und Lesen und funktioniert gut für einfache Stories und für Teams, die manuell testen.

Story: Als wiederkehrender Kunde möchte ich mein Passwort per E-Mail zurücksetzen, damit ich wieder auf mein Konto zugreifen kann, ohne den Support zu kontaktieren.

• Der Login-Bildschirm hat einen Link „Passwort vergessen?“, der das Zurücksetzungsformular öffnet.
• Das Absenden einer registrierten E-Mail-Adresse sendet einen Reset-Link innerhalb einer Minute.
• Der Reset-Link funktioniert einmalig und läuft nach 30 Minuten ab.
• Das neue Passwort muss die bestehenden Passwortregeln erfüllen, und das Formular zeigt an, welche Regel nicht erfüllt wurde.
• Nach einem erfolgreichen Zurücksetzen werden alle anderen Sitzungen für dieses Konto abgemeldet.
• Das Absenden einer nicht registrierten Adresse zeigt dieselbe Bestätigungsmeldung wie eine registrierte Adresse, sodass das Formular nicht offenlegt, wer ein Konto hat.

Verwenden Sie die Checkliste, wenn das Verhalten eindeutig ist. Ihr Nachteil ist, dass sie den Ausgangszustand und die Reihenfolge der Ereignisse verbirgt, die das nächste Format explizit macht.

Format 2: Given/When/Then (Gherkin) Akzeptanzkriterien

Given/When/Then stammt aus der verhaltensgetriebenen Entwicklung, die Dan North mit Chris Matts in Introducing BDDbeschrieben haben. Jedes Szenario definiert einen Ausgangskontext (Given), eine Aktion (When) und ein erwartetes Ergebnis (Then). Gherkin ist die strukturierte Version dieser Sprache, die von Cucumber und ähnlichen Tools verwendet wird, sodass Szenarien, die auf diese Weise geschrieben werden, mit geringfügigen Umformulierungen zu automatisierten Tests werden können.

Hier ist dieselbe Passwort-Reset-Geschichte als drei Szenarien, einschließlich zweier Fehlerpfade.

Szenario 1: Zurücksetzen mit einem gültigen Link

• Angenommen, ich habe ein Konto, das unter anna@example.com registriert ist
• Und ich habe ein Passwort-Reset angefordert
• Wenn ich den Reset-Link innerhalb von 30 Minuten öffne und ein neues Passwort eingebe, das den Regeln entspricht
• Dann wird mein Passwort geändert
• Und ich bin angemeldet
• Und meine anderen Sitzungen werden abgemeldet

Szenario 2: Der Link ist abgelaufen

• Angenommen, ich habe ein Passwort-Reset vor mehr als 30 Minuten angefordert
• When ich den Reset-Link öffne
• Then sehe ich eine Nachricht, dass der Link abgelaufen ist
• Und mir wird ein Button angeboten, um einen neuen Link zu senden

Szenario 3: Die E-Mail-Adresse ist nicht registriert

• Angenommen, es existiert kein Konto für sam@example.com
• Wenn ich ein Passwort-Reset für sam@example.com anfordere
• Dann sehe ich dieselbe Bestätigungsmeldung wie ein registrierter Benutzer
• Und es wird keine E-Mail gesendet

Wenn ein Szenario mit mehreren Eingaben ausgeführt werden muss (z. B. eine Liste von Passwörtern, die abgelehnt werden sollen), ermöglicht Gherkins Szenario-Outline, es einmal zu schreiben und die Eingaben in einer Beispieltabelle aufzulisten.

Halten Sie Gherkin lesbar: ein Verhalten pro Szenario, und schreiben Sie deklarativ („Wenn ich einen Reset-Link anfordere“) statt klickweise („Wenn ich auf den Senden-Button klicke“), damit das Szenario ein Redesign übersteht.

Format 3: regelbasierte Akzeptanzkriterien

Für Geschichten, die hauptsächlich aus Geschäftsregeln bestehen (Preise, Berechtigung, Validierung, Berechtigungen), formulieren Sie die Regeln direkt und fügen Sie Szenarien nur für die schwierigen Kombinationen hinzu.

Geschichte: Als Käufer möchte ich einen Rabattcode beim Checkout anwenden, damit ich den Aktionspreis zahle.

• Regel 1: ein Code pro Bestellung.
• Regel 2: ein Prozentcode wird nur auf den Produktzwischensumme angewendet, nicht auf Versand oder Steuern.
• Regel 3: ein Code mit Mindestbestellwert gilt nur, wenn der Zwischensumme, vor dem Rabatt, den Mindestwert erreicht.
• Regel 4: abgelaufene oder aufgebrauchte Codes werden mit einer Meldung abgelehnt, die den Grund angibt.
• Regel 5: das Entfernen von Artikeln, sodass der Zwischensumme unter den Mindestwert fällt, entfernt den Code und zeigt eine Benachrichtigung an.

Sie können in einer Story verschiedene Formate kombinieren. Ein gängiges Muster ist die Verwendung von Regeln für die Logik plus zwei oder drei Given/When/Then-Szenarien für die Fälle, die am ehesten missverstanden werden.

Definition of Ready vs. Definition of Done

Abnahmekriterien sind spezifisch für eine einzelne Story. Die Definition of Ready und die Definition of Done sind teamweite Vereinbarungen, die auf jede Story anwendbar sind.

Die Scrum Guide definiert die Definition of Done als die formale Beschreibung des Zustands des Inkrements, wenn es die für das Produkt erforderlichen Qualitätsmaßstäbe erfüllt. Die Definition of Ready ist nicht Teil von Scrum; es ist eine Praxis, die viele Teams übernehmen, um sicherzustellen, dass halb verstandene Arbeit nicht in einen Sprint einfließt (siehe das Glossar der Agile Alliance zu Definition of Ready und Definition of Done).

Beispiel für eine Definition of Ready

• Die Story folgt dem Template und das „so that“ ist ausgefüllt.
• Abnahmekriterien werden von Produkt, Entwicklung und Test erstellt und geprüft.
• Designs sind verlinkt, oder das Team hat vereinbart, dass keine benötigt werden.
• Abhängigkeiten sind erledigt oder geplant.
• Das Team hat sie geschätzt, und sie passt in einen Sprint.

Beispiel für eine Definition of Done

• Alle Abnahmekriterien werden erfüllt.
• Code ist geprüft und in den Hauptzweig gemergt.
• Automatisierte Tests decken das neue Verhalten ab und die gesamte Testsuite besteht.
• Grundlegende Barrierefreiheitstests bestehen (Tastaturbedienung, Beschriftungen, Kontrast).
• Es wurde in die Staging-Umgebung deployed und der Product Owner hat es akzeptiert.

Behandle die Definition of Ready als Checkliste zur Verfeinerung, nicht als Tor. Wenn ein Team jede Story ablehnt, die ein Kriterium nicht erfüllt, verlangsamt sich die Arbeit und das Gespräch, das die Story auslösen sollte, findet nie statt.

Beispiele aus der Praxis

Zwei weitere Stories aus verschiedenen Produktarten. Für vierzig weitere siehe unsere Beispielen für User Stories.

SaaS: Teammitglied einladen (Checkliste)

Als Workspace-Admin möchte ich ein Teammitglied per E-Mail einladen, damit es unsere Projekte sehen kann, ohne dass ich meinen Login teile.

• Admins sehen auf der Mitgliederseite eine „Einladen“-Schaltfläche; andere Rollen nicht.
• Der Admin kann die Rolle (Member oder Admin) vor dem Senden auswählen.
• Die Einladungs-E-Mail kommt innerhalb einer Minute an und der Link ist sieben Tage gültig.
• Wenn eine Adresse eingeladen wird, die bereits Mitglied ist, wird eine Nachricht angezeigt, anstatt eine zweite Einladung zu senden.

E-Commerce: Artikel für später speichern (Given/When/Then)

Als Käufer, der noch nicht bereit ist zu kaufen, möchte ich einen Artikel aus meinem Warenkorb in eine gespeicherte Liste verschieben, damit ich ihn später wiederfinden kann, ohne dass er meinen Bestellwert beeinflusst.

• Angenommen, ich bin angemeldet und habe zwei Artikel in meinem Warenkorb
• Wenn ich bei einem Artikel „Für später speichern“ wähle
• Dann wird dieser Artikel in meine gespeicherte Liste verschoben
• Und mein Warenkorbgesamtwert wird ohne ihn neu berechnet
• Angenommen, ich bin nicht angemeldet
• Wenn ich „Für später speichern“ wähle
• Dann werde ich aufgefordert, mich anzumelden, und der Artikel wird gespeichert, sobald ich das tue

Verwendung der Vorlage in Jira, Linear, Notion oder einer Tabelle

In Jira den Issue-Typ „Story“ verwenden und die Vorlage in die Beschreibung einfügen (oder die Akzeptanzkriterien in einem dedizierten Feld hinterlegen, falls Ihr Admin eines hinzugefügt hat). In Linear als Issue-Vorlage speichern. In Notion in eine Datenbankvorlage einfügen, damit neue Backlog-Seiten vorausgefüllt geöffnet werden. Eine Tabelle mit einer Zeile pro Story funktioniert für ein erstes Backlog oder ein Workshop, aber wechseln Sie zu einem Tracker, sobald mehrere Personen es bearbeiten. Egal welches Tool: Halten Sie die Vorlage kurz genug, damit sie ausgefüllt wird.

Storys und Akzeptanzkriterien mit KI erstellen

Sprachmodelle sind gut für einen ersten Entwurf von Stories und Kriterien. Ein funktionierender Prompt:

Du bist ein Product Manager. Für die folgende Funktion schreibe User Stories im Format „Als [Benutzer], möchte ich [Aktion], damit [Nutzen]“. Für jede Story füge 3 bis 6 Akzeptanzkriterien in Given/When/Then-Form hinzu, einschließlich mindestens eines Fehlerpfads. Liste alle Annahmen und offenen Fragen separat auf. Funktion: [beschreibe die Funktion, die Benutzer und eventuelle Einschränkungen].

Prüfe den Entwurf dann wie jede andere Eingabe:

• Ist der Benutzer ein reales Segment, mit dem Sie gesprochen haben, oder ein generischer „Benutzer“?
• Hat das Modell Geschäftsregeln, Grenzen oder Zahlen erfunden? Ersetzen Sie sie durch Ihre eigenen.
• Sind die Fehlerpfade diejenigen, die Ihre Benutzer tatsächlich antreffen? Ein Entwurf ersetzt nie das Verfeinerungsgespräch.

Häufig gestellte Fragen

Möchten Sie, dass ein Team Ihre Stories in funktionierende Software verwandelt? Bringen Sie Ihr Backlog oder nur die Idee mit, und wir helfen Ihnen, sie in sprint-gerechte Stories zu formen und zu bauen. Siehe unsere monatlichen Entwicklungspläne.