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 [Vorteil] 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 Pass/Fail-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 zu schummeln

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 in den Wortschatz des Benutzers; „Ich möchte einen Microservice zur Passwortzurücksetzung“ gehört in das 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 konkrete 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, ergänzt um die Story, die Kriterien, die Grenzen und zuletzt den Umfang:

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 stehen hinter dieser Karte. „Außerhalb des Umfangs“ ist entscheidend: Bei den meisten Diskussionen über Schätzungen versuchen zwei Personen, unterschiedliche Umfangsbereiche einzuschätzen, und eine einzige Zeile hier verhindert dies. Die Größe kommt zuletzt: Eine Zahl, die auf die Karte geschrieben wird, bevor das Team darüber diskutiert, wird zu einem Anker – was der erste der klassischen Fehler beim Planning Poker ist.

Vorlagenvarianten

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

Variante	Form	Greifen Sie danach, wenn
Classic (Connextra)	Als [Rolle] möchte ich [Ziel] erreichen, damit [Vorteil]	Der Standard für kundenorientierte Arbeit
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 [Rolle] [Ziel] erreichen	Das Team formuliert immer wieder zirkuläre Begründungen; 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 Nutzer 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 Formulierung 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 Aufgaben: 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 gespeichert.
• Ein wiederkehrender Kunde sieht den Warenkorb von jedem Gerät aus, 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 dem Hinweis „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 Kostenschä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 E-Mail mit der Auftragsbestätigung bietet die Möglichkeit, mit einem Klick ein Konto zu erstellen (Auftrag 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 des Aufwands 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, 8. Die 8 erklärt sich wie folgt: Das Kriterium zur Betrugsprüfung bedeutet, dass die Integration des Zahlungsanbieters berührt wird, was sonst niemand in die Kalkulation einbezogen hatte. So erfüllen die Kriterien ihren eigentlichen Zweck: 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, unlösbaren Spannen, die die Sizing-Sitzungen zum Stillstand bringen. Das Team stimmt letztendlich ü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“-Muster, 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 an das 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 eignen sich besonders gut, wenn der auslösende Moment die Anforderung besser verdeutlicht 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 (ein klar formulierter Grund und überprüfbare Akzeptanzkriterien), und passen Sie die Satzstruktur an die jeweilige 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 Beispiele als Orientierungshilfe.
• Akzeptanzkriterien: Wie man sie verfasst – das vollständige Kapitel zum Bestätigungsschritt.
• Definition von „bereit“: Die Hürde, die eine vorlagenbasierte 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.