Vorlage für User Stories und Akzeptanzkriterien

Die Vorlage für eine User Story besteht aus einem Satz mit drei Lücken:

Als [Rolle] möchte ich [Ziel] erreichen, damit [Nutzen] entsteht.

Kopieren Sie sie, nutzen Sie sie, aber seien Sie sich bewusst, wozu sie dient: Die Vorlage ist ein Anstoß für ein Gespräch, kein Formular, das ausgefüllt werden muss. Ein ausgefüllter Satz ist der Punkt, an dem die Verfeinerung beginnt. Was die Story umsetzbar macht, ist das, was als Nächstes hinzukommt – die Akzeptanzkriterien, die eine vereinbarte Absicht in einen Bestanden/Nicht bestanden-Test verwandeln, und die Schätzung, die daraus planbare Arbeit macht. Dieses Kapitel führt eine Story durch alle drei Schritte.

Die Lücken ausfüllen, ohne dabei etwas zu erfinden

Jeder Zylinder weist einen typischen Zündausfall auf, und jeder Zündausfall lässt sich überprüfen:

• [Rolle] – eine bestimmte Person, niemals „ein Nutzer“. Wenn Sie diese Person nicht anhand Ihrer Analysedaten oder Ihrer Support-Warteschlange identifizieren könnten, ist die Rolle reine Dekoration. Test: Könnte ein Designer aufgrund der von Ihnen gewählten Rolle eine Entscheidung anders treffen?
• [Ziel] – was die Person tut, in ihren eigenen Worten. „Ich möchte mein Passwort zurücksetzen“ gehört zum Benutzer; „Ich möchte einen Microservice zur Passwortzurücksetzung“ gehört zum Architekturdiagramm. Test: Würde die Person diesen Satz tatsächlich sagen?
• [Nutzen] – das Argument für die Planung der Arbeit. Test: Löschen Sie die Klausel. Wenn dadurch nichts verloren geht, wurde der Nutzen noch nicht ermittelt.

Die vollständige Begründung für dieses Format – einschließlich der drei Cs und der INVEST-Checkliste, die eine fertige User Story erfüllen sollte – finden Sie unter Was ist eine User Story?. Sechzehn praktische Beispiele, sowohl gute als auch schlechte, finden Sie unter Beispiele für User Stories.

Eine Story-Karte zum Kopieren und Einfügen

Dieser Satz allein reicht nicht aus, um ihn in einen Sprint aufzunehmen. Hier ist das vollständige Kartenformat, das als Standard dienen sollte – Story, Kriterien, Grenzen und zuletzt die Größe:

Story
  As a [role], I want [goal], so that [benefit].

Acceptance criteria (3–5, each pass/fail)
  - [ ] …
  - [ ] …
  - [ ] …

Out of scope
  - What this story deliberately does NOT cover.

Notes & dependencies
  - Designs, decisions, other teams, open questions.

Size: [added by the team, after the conversation — never before]

Zwei bewusste Entscheidungen in dieser Karte. „Out of scope“ ist entscheidend: Bei den meisten Diskussionen über Schätzungen geht es darum, dass zwei Personen unterschiedliche Umfangsbereiche einschätzen, und eine einzige Zeile hier verhindert dies. Die Größe wird zuletzt festgelegt: Eine Zahl, die auf die Karte geschrieben wird, bevor das Team darüber diskutiert, wird zu einem Anker – dies ist der erste der klassischen Fehler beim Planning Poker.

Vorlagenvarianten

Die klassische Vorlage ist die richtige Standardeinstellung, und sie ist nicht die einzige Form, die funktioniert.

Variante	Form	Greifen Sie danach, wenn
Classic (Connextra)	Als [Rolle] möchte ich [Ziel] erreichen, damit [Vorteil]	Die Standardvorgehensweise bei kundenorientierten Aufgaben
Berufsgeschichte	Wenn [Situation] eintritt, möchte ich [Motivation], damit ich [Ergebnis] erreichen kann.	Der auslösende Moment sagt mehr aus als die Rolle – dieselbe Person wünscht sich im Zug etwas anderes als am Schreibtisch
Der Nutzen steht an erster Stelle	Um [Vorteil] zu erzielen, möchte ich als [Funktion] [Ziel] erreichen	Das Team formuliert die Vorteile immer wieder in zirkulärer Weise; wenn man die Klausel an den Anfang stellt, lässt sie sich nicht mehr überspringen
Einfache Problemstellung	Ein Satz zur Problemstellung, ein Satz zum Ergebnis sowie Kriterien für den Abschluss	Plattform- und technische Arbeit, bei der das Team selbst die einzige authentische Instanz wäre

Die letzte Zeile ist wichtiger, als es auf den ersten Blick scheint. Bei einigen Backlog-Elementen wird im Satz kein Benutzer genannt, und wenn man so tut, als wäre dies der Fall, entstehen Füllsätze wie „Als Entwickler möchte ich, dass das Framework aktualisiert wird.“ Die Struktur der Vorlage – ein klar formulierter Grund sowie überprüfbare Kriterien – lässt sich auf diese Arbeit übertragen; die formale Gestaltung des Satzes muss dies jedoch nicht.

Abnahmekriterien: die Bestätigung auf der Karte

Akzeptanzkriterien sind die Bedingungen, anhand derer eine Story als bestanden oder nicht bestanden gewertet wird, und werden vor Beginn der Arbeit festgelegt. Auf der Karte erfüllen sie zwei Funktionen: Sie halten fest, worauf man sich im Rahmen des Verfeinerungsgesprächs tatsächlich geeinigt hat, und sie definieren die Ziellinie, an der sich die Schätzung orientieren wird. Zwei Formate decken nahezu jede Story ab:

Eine einfache Checkliste für unabhängige Bedingungen:

• Der Inhalt des Warenkorbs bleibt über mehrere Sitzungen hinweg 30 Tage lang erhalten.
• Ein wiederkehrender Kunde kann den Warenkorb von jedem Gerät aus einsehen, auf dem er angemeldet ist.
• Ein geleerter Warenkorb bleibt leer (entfernte Artikel werden nicht wiederhergestellt).

Given/When/Then, für Verhaltensweisen, die vom Zustand abhängen:

• Wenn ein Kunde einen gespeicherten Warenkorb hat, und ein Artikel nicht mehr vorrätig ist, dann wird der Artikel im Warenkorb ausgegraut und mit der Bezeichnung „nicht vorrätig“ angezeigt, anstatt ihn stillschweigend zu entfernen.

Verwenden Sie standardmäßig die Checkliste; greifen Sie auf „Given/When/Then“ zurück, wenn die Vorbedingung eine konkrete Aufgabe erfüllt. Beschränken Sie die Liste auf drei bis fünf Einträge – eine längere Liste bedeutet in der Regel, dass die Story aufgeteilt werden sollte, und die Kriterien zeigen Ihnen die Trennlinien auf. Eine ausführliche Erläuterung (Kriterien vs. Anforderungen, Kriterien vs. Definition of Done, wer sie verfasst) finden Sie im Kapitel über Akzeptanzkriterien.

Beispiel: Ein Stockwerk, Vorlage zur Schätzung

So verläuft der Verlauf einer echten Geschichte anhand der obigen Karte.

Schritt 1 – die Story. Der Product Owner schreibt:

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.

Schritt 2 – das Gespräch, festgehalten als Kriterien. Bei der Backlog-Verfeinerung bringt das Team die Nuancen zur Sprache, die der Satz nicht vermittelt, und hält diese schriftlich fest:

• Ein Käufer kann den Bestellvorgang lediglich mit seiner E-Mail-Adresse und den Versanddaten abschließen, ohne ein Passwort anzugeben.
• Die Bestellbestätigungs-E-Mail bietet die Möglichkeit, mit einem Klick ein Konto zu erstellen (Bestellung bereits beigefügt).
• Eine Gastbestellung kann vom Support anhand der Bestellnummer und der E-Mail-Adresse ermittelt werden.
• Beim Gast-Checkout werden dieselben Betrugsprüfungen durchgeführt wie beim Checkout über ein Konto.

Nicht im Geltungsbereich: Die Umwandlung früherer Gastbestellungen, wenn ein Konto nachträglich angelegt wird.

Schritt 3 – die Bereitschaftsprüfung. Vier Kriterien, ein benannter Ausschlussgrund, keine unbestätigten Abhängigkeiten: Die Story erfüllt die Definition der Bereitschaft und wird zur Einschätzung an das Team weitergeleitet.

Schritt 4 – die Schätzung. Das Team stimmt in einer Runde Planning Poker ab. Es fallen die Karten 3, 5, 5 und 8. Die 8 erklärt sich wie folgt: Das Kriterium zur Betrugsprüfung erfordert eine Anpassung der Integration des Zahlungsanbieters, was sonst niemand in die Schätzung einbezogen hatte. Hier zeigen die Kriterien ihre eigentliche Wirkung – bei der Diskussion geht es um den Umfang, nicht darum, wessen Zahl richtig ist. Das Team stimmt erneut ab und einigt sich auf 5.

Beachten Sie die Vorgehensweise: Zuerst die Kriterien, dann die Punkte. Eine Story, deren Umfang geschätzt wird, bevor die Kriterien feststehen, führt zu weit gefassten, nicht lösbaren Spannen, die die Sizing-Sitzungen zum Stillstand bringen – das Team stimmt über verschiedene Stories ab, die zufällig denselben Titel tragen.

Häufig gestellte Fragen

Was ist die Vorlage für eine User Story?

„Als [Rolle] möchte ich [Ziel], damit [Nutzen].“ Die Rolle benennt, wer den Nutzen erhält, das Ziel beschreibt die Fähigkeit aus der Perspektive dieser Person, und der Nutzen ist der Grund, warum die Aufgabe einen Platz im Backlog verdient. Die Vorlage dient als Anregung für ein Gespräch und nicht als Formular, das ausgefüllt werden muss – das Ausfüllen der Lücken ist der Beginn der Verfeinerung.

Wie formuliert man Akzeptanzkriterien für eine User Story?

Formulieren Sie drei bis fünf überprüfbare Bedingungen, die mit „bestanden“ oder „nicht bestanden“ angeben, ob die Story das Vereinbarte erfüllt hat. Verwenden Sie eine einfache Checkliste, wenn die Bedingungen unabhängig voneinander sind, und das „Given/When/Then“-Schema, wenn das Verhalten vom Zustand abhängt. Jedes Kriterium sollte von einem Tester überprüft werden können, der nicht an der Verfeinerungssitzung teilgenommen hat.

Sollten Akzeptanzkriterien nach dem „Given/When/Then“-Prinzip oder anhand einer Checkliste formuliert werden?

Passen Sie das Format dem Verhalten an. „Given/When/Then“ bewährt sich besonders dann, wenn das Ergebnis von einem Ausgangszustand abhängt, da es Sie dazu zwingt, die Vorbedingung, den Auslöser und das Ergebnis zu benennen. Eine Checkliste lässt sich schneller lesen und ist schwerer zu überfrachten, wenn die Story lediglich lautet: „Diese vier Dinge müssen zutreffen.“ Für die meisten Stories reicht die Checkliste aus.

Was ist eine „Job-Story“?

Eine Variante, bei der die Persona durch eine Situation ersetzt wird: „Wenn [Situation], möchte ich [Motivation], damit ich [Ergebnis] erreichen kann.“ Job-Stories stammen aus der „Jobs-to-be-Done“-Schule und funktionieren gut, wenn der auslösende Moment die Anforderung besser erklärt als eine Persona – dieselbe Person hat am Schreibtisch andere Bedürfnisse als im Zug.

Benötigt jedes Backlog-Element die User-Story-Vorlage?

Nein. Die Vorlage beschreibt den für den Nutzer erkennbaren Nutzen, und wenn man sie auf Plattformarbeit, bekannte Fehler oder Forschungsschwerpunkte anwendet, entstehen Sätze, die zwar den Formalkontext betonen, aber keinen zusätzlichen Informationsgehalt bieten. Behalten Sie die beiden Elemente bei, die stets übertragbar sind – einen klar formulierten Grund und überprüfbare Akzeptanzkriterien – und passen Sie die Satzstruktur der jeweiligen Aufgabe an.

Weiterführende Literatur

• Agile Schätzung: Der umfassende Leitfaden – hier finden Sie alles zum Thema.
• Was ist eine User Story? – die Gründe für die Vorlage: die drei Cs und INVEST.
• Beispiele für User Stories – sechzehn kommentierte User Stories als Referenz.
• Akzeptanzkriterien: Wie man sie verfasst – das vollständige Kapitel zum Bestätigungsschritt.
• Definition von „ready“ – die Hürde, die eine vorlagengestützte Story auf ihrem Weg in den Sprint nehmen muss.
• Was sind Story-Punkte? – die Maßeinheit, anhand derer die Größe der fertigen Karte bestimmt wird.