Vorlage für User Stories und Abnahmekriterien

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 zu schummeln

Jeder Zylinder weist eine typische Fehlzündung auf, und jede Fehlzündung lässt sich überprüfen:

• [Rolle]: eine bestimmte Person, niemals „ein Nutzer“. Wenn Sie diese Person weder in Ihren Analysedaten noch in 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 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 die vollständige Kartenvorlage, die als Standard dienen sollte, mit Story, Kriterien, Grenzen und einer zuletzt hinzugefügten 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. „Außerhalb des Umfangs“ ist entscheidend: Bei den meisten Diskussionen über Schätzungen beurteilen zwei Personen unterschiedliche Projektumfänge, und eine einzige Zeile hier verhindert dies. Die Größe kommt erst an letzter Stelle: Eine Zahl, die auf die Karte geschrieben wird, bevor das Team darüber diskutiert, wird zum Anker – und das 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]	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 möchte im Zug etwas anderes als am Schreibtisch)
Der Nutzen steht an erster Stelle	Um [Vorteile] zu erzielen, möchte ich als [Funktion] [Ziel] erreichen	Das Team formuliert immer wieder zirkuläre Vorteile; wenn man die Klausel an den Anfang stellt, lässt sie sich nicht ü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 den Anschein hat. Bei einigen Backlog-Elementen kommt im Satz kein Nutzer vor, 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, was im Rahmen des Verfeinerungsgesprächs tatsächlich vereinbart wurde, und sie definieren die Ziellinie, an der sich die Schätzung orientiert. 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 kann den Warenkorb von jedem Gerät aus einsehen, auf dem er angemeldet ist.
• Ein geleerter Warenkorb bleibt leer (entnommene 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 Angabe „nicht vorrätig“ gekennzeichnet, 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 Ablauf einer echten Geschichte anhand der obenstehenden 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 – ganz ohne Passwort.
• Die E-Mail mit der Bestellbestätigung bietet die Möglichkeit, mit einem Klick ein Konto zu erstellen (die Bestellung ist bereits angehängt).
• 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 Umfang enthalten: Die Umwandlung früherer Gastbestellungen, wenn später ein Konto 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 Zahlen 3, 5, 5 und 8. Die 8 lässt sich wie folgt erklären: Das Kriterium der Betrugsprüfung erfordert eine Anpassung der Integration des Zahlungsanbieters, was sonst niemand in seine Schätzung 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 gibt an, 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 Ergebnis geliefert 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“ macht sich besonders dann bezahlt, wenn das Ergebnis vom 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 aufzublähen, wenn die Story lediglich besagt: „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] 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 formell korrekt sind, aber keinen zusätzlichen Informationsgehalt bieten. Behalten Sie die beiden Elemente bei, die stets übertragbar sind (ein klar formulierter Grund und überprüfbare Abnahmekriterien), und passen Sie die Satzstruktur der jeweiligen Aufgabe an.

Weiterführende Literatur

• Agile Schätzung: Der umfassende Leitfaden: Hier finden Sie alles zu diesem 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 Geschichten, an denen Sie sich orientieren können.
• 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 der Umfang der fertigen Karte bestimmt wird.