Was eine User Story ausmacht: Aufbau, Beispiele und Tipps

Der Satz "Als Kunde möchte ich Produkte nach Preis filtern, damit ich im Budget bleibe" wirkt unscheinbar. Er ist aber der Ausgangspunkt eines Gesprächs zwischen allen, die neue Funktionen konzipieren, entwickeln und testen.

Die Einfachheit des Formats kann allerdings täuschen. Ohne den Zweck dahinter zu verstehen, landen manche Teams bei User Stories, die eher an technische Issues erinnern als an ein Gespräch über den angestrebten Nutzen.

Dieser Artikel zeigt, was eine User Story wirklich umfasst und wie sie sich so formulieren lässt, dass das Team sie ohne Unklarheiten und unnötige Rückfragen umsetzen kann.

→ GitLab Ultimate kostenlos testen

Definition der User Story

Eine User Story ist eine einfache, knappe Beschreibung einer Anforderung aus Sicht der Endnutzer(innen). In einem Satz hält sie fest, wer was braucht und warum.

Das Konzept entstand Ende der 1990er-Jahre im Extreme Programming, der von Kent Beck begründeten Methode. Dort wurden User Stories als frei formulierte Karten ohne feste Vorlage eingeführt. Anfang der 2000er-Jahre formalisierte ein britisches Team bei Connextra die heute verbreitetste Vorlage "Als Rolle möchte ich Ziel, damit Nutzen". Breit bekannt wurde sie vor allem durch Mike Cohn und sein Standardwerk User Stories Applied (2004). Seitdem gehört sie zum Standard agiler Teams, insbesondere in Scrum.

Die User Story beschreibt das Was und lässt das Wie offen. Indem sie die Anforderung und den erwarteten Nutzen benennt, ohne die Lösung vorzugeben, lässt sie dem Entwicklungsteam die Freiheit, die Umsetzung selbst zu wählen. Genau darin unterscheidet sie sich grundlegend von einem Lastenheft. Das Lastenheft legt Entscheidungen fest, bevor das Gespräch überhaupt beginnt. Die User Story lässt diese Entscheidungen bewusst offen, damit sie im Austausch reifen.

Der Aufbau einer User Story

Die Connextra-Vorlage folgt einem festen Muster: Als [Rolle] möchte ich [Ziel], damit [Nutzen]. Die Rolle verortet die Person, das Ziel beschreibt, was sie erreichen will, und der Nutzen, also das entscheidende Warum, gibt dem Satz seinen Sinn.

Gerade der letzte Teil, das damit, wird jedoch am häufigsten vernachlässigt, obwohl er den eigentlichen Wert der User Story trägt. Ein Vergleich: "Als Nutzer möchte ich einen Export-Button" und "Als Buchhalter möchte ich meine Buchungen als CSV exportieren, damit ich sie ohne erneute Eingabe in meine Buchhaltungssoftware importieren kann". Die zweite Fassung erklärt dem Team, warum es die Funktion gibt, und lässt ihm Raum, eine bessere Lösung vorzuschlagen, wenn es eine sieht.

Ron Jeffries fasste die Idee in drei Cs zusammen:

• Die Card (Karte) trägt den Satz und ist zwangsläufig kurz.
• Die Conversation (Gespräch) umfasst den Austausch, der die Anforderung schärft.
• Die Confirmation (Bestätigung) bündelt die Akzeptanzkriterien, mit denen sich prüfen lässt, ob die Anforderung erfüllt ist.

Die Card hat nur dann Wert, wenn sie ein Gespräch auslöst, das eine schriftliche Anforderung in eine gemeinsame Lösung verwandelt. Eine User Story, die keinen Austausch anstößt, hat ihre Aufgabe nur zum Teil erfüllt.

Die User Story in der Teamarbeit

Wer User Stories gut nutzen will, sollte wissen, wo sie stehen: zwischen dem strategischen Ziel eines Epics und dem Umsetzungsdetail einer Aufgabe.

Epic, User Story und Aufgabe im Vergleich

An der Spitze dieser Hierarchie steht das Epic, ein übergeordnetes Ziel, das mehrere User Stories mit demselben Zweck bündelt, etwa "Besucher(inne)n ermöglichen, ein Konto anzulegen". Die User Story greift daraus einen konkreten, lieferbaren Ausschnitt heraus, zum Beispiel "meine E-Mail-Adresse und ein Passwort eingeben, um mein Konto anzulegen". Die Aufgabe schließlich bewegt sich auf der reinen Umsetzungsebene, ohne eigene Nutzer(innen) und ohne eigenen Nutzen, etwa "das E-Mail-Format serverseitig validieren".

Jede Ebene hat ihren eigenen Zeithorizont. Die Richtwerte unterscheiden sich von Team zu Team. Das Scrum-Tutorial von GitLab setzt für ein Epic eine Iteration an, für eine User Story einige Tage und für eine Aufgabe einige Stunden bis einen Tag. Andere Organisationen lassen ihre Epics über mehrere Iterationen laufen. Entscheidend ist, dass das Team dieselbe Konvention teilt.

Die User Story im Backlog

In der agilen Softwareentwicklung fließen all diese User Stories in das Product Backlog ein, die priorisierte Liste der Anforderungen, die auf ihre Umsetzung warten. Der Product Owner ordnet sie nach Nutzen und Rahmenbedingungen des Projekts, und das Team wählt bei der Sprintplanung die wichtigsten aus.

Merkmale einer guten User Story

Eine gut geschriebene User Story zeichnet sich durch einige Kriterien aus, die schon beim Schreiben prüfbar sind, lange bevor die erste Zeile Code entsteht. Zusammengefasst werden sie oft mit dem Akronym INVEST, das Bill Wake 2003 formulierte.

Die sechs Eigenschaften nach INVEST

• Independent (unabhängig): lässt sich entwickeln, ohne auf eine andere User Story zu warten. Gemeint ist Unabhängigkeit auf fachlicher Ebene, nicht auf technischer, wo Abhängigkeiten normal bleiben.
• Negotiable (verhandelbar): kann sich ändern, bis sich das Team verpflichtet, sie umzusetzen.
• Valuable (wertvoll): bringt den Nutzer(inne)n oder dem Fachbereich einen konkreten Nutzen.
• Estimable (schätzbar): lässt sich in Komplexität und Aufwand einschätzen, meist in Story Points.
• Small (klein): umfasst höchstens einige Tage Arbeit.
• Testable (testbar): Akzeptanzkriterien erlauben eine eindeutige Prüfung, ob die Anforderung erfüllt ist.

Akzeptanzkriterien als prüfbare Bedingungen

Akzeptanzkriterien beschreiben die genauen Bedingungen, unter denen eine User Story als erfüllt gilt. Häufig werden sie im Format "Angenommen / Wenn / Dann" geschrieben. Es stammt aus dem Behaviour-Driven Development (BDD) von Dan North und wurde in der Gherkin-Syntax formalisiert: "Angenommen [Kontext], wenn [Aktion], dann [erwartetes Ergebnis]". Eine Liste einfacher Bedingungen erfüllt aber denselben Zweck.

Für die User Story mit dem Preisfilter könnte ein Akzeptanzkriterium so lauten: "Angenommen, eine Produktliste wird angezeigt, wenn ich einen Höchstpreis festlege, dann erscheinen nur Artikel, deren Preis diesen Höchstpreis nicht übersteigt."

Manche Teams vernachlässigen diesen Schritt jedoch, und viele User Stories gehen ohne ein einziges Akzeptanzkriterium in die Entwicklung. Die User Story bleibt dann mehrdeutig, jede Person legt das erwartete Ergebnis anders aus, und am Sprintende häufen sich teure Korrekturschleifen. Einige gut formulierte Kriterien, meist drei bis fünf, genügen, um das Team auf das erwartete Ergebnis auszurichten.

Schritt für Schritt zur User Story

Eine gute User Story folgt immer derselben Logik, ganz gleich, um welches Produkt es geht:

1. Die tatsächlichen Nutzer(innen) über eine konkrete Persona bestimmen, damit sich das Team besser in sie hineinversetzen kann.
2. Ihr Ziel erfassen, also das, was sie in ihrem Kontext erreichen wollen.
3. Den Nutzen formulieren, das entscheidende "damit", und dabei fragen, warum dieses Ziel für sie zählt.
4. Die User Story nach der Vorlage schreiben, in einfacher Sprache und ohne technische Vorgaben.
5. Die Akzeptanzkriterien festlegen, die bestimmen, wann die User Story als erfüllt gilt.

Für eine Banking-App könnte das so aussehen: "Als Kontoinhaber möchte ich mein vergessenes Passwort zurücksetzen, damit ich ohne Anruf beim Support wieder Zugang zu meinem Konto erhalte."

Die Rolle ist klar benannt, das Ziel unmissverständlich und der Nutzen konkret. Die Akzeptanzkriterien ergeben sich daraus fast von selbst: Ein Link kommt per E-Mail und läuft nach einer festgelegten Zeit ab, und das neue Passwort muss der Sicherheitsrichtlinie entsprechen. Gut formuliert erleichtert eine solche User Story Entwicklung und Tests, ohne den restlichen Sprint zu bremsen.

Typische Fehler

Der erste Fehler besteht darin, eine technische Aufgabe als User Story zu tarnen. "Als Nutzer möchte ich eine PostgreSQL-Datenbank mit einem Index auf dem Titel" beschreibt eine Umsetzung, keine Anforderung aus Sicht der Nutzer(innen). Sobald das "Als" eine technische Rolle verbirgt und das "damit" auf eine Umsetzungsentscheidung verweist, verliert die User Story jeden Bezug zu den Nutzer(inne)n.

Der zweite häufige Fehler ist eine zu große User Story. Lässt sie sich kaum schätzen oder im Sprint nicht abschließen, steckt darin meist mehr als eine.

Beim Zerlegen hilft der vertikale Schnitt (Vertical Slicing). Statt die Arbeit nach technischen Schichten aufzuteilen, also das Backend auf der einen und das Frontend auf der anderen Seite, orientiert er sich am Weg der Nutzer(innen) und zerlegt die Arbeit in eigenständige fachliche Teile, die sich jeweils unabhängig testen lassen. Bei der Kontoerstellung ergeben sich so drei getrennte User Stories: E-Mail-Adresse eingeben, Passwort wählen und die Registrierung abschließen.

Als Richtwert für die Größe nennt das Scrum-Tutorial von GitLab etwa vier bis zehn User Stories pro Sprint für ein Team. Jede User Story ist dabei so klein, dass eine Person sie in ein bis zwei Tagen umsetzen kann. Schließt das Team deutlich weniger ab, sind die User Stories womöglich zu groß oder müssen noch geklärt oder zerlegt werden. Schließt es deutlich mehr ab, sollte es prüfen, ob sie noch einen eigenen Nutzen bringen und nicht zu bloßen technischen Schritten geworden sind.

Zwei weitere Fehler runden das Bild ab: ein übergangenes oder fehlendes "damit", das dem Team das Warum vorenthält, und fehlende Akzeptanzkriterien, wie oben beschrieben. Keiner dieser Fehler ist für sich genommen fatal. In der Summe machen sie aus einem Backlog jedoch eine undurchsichtige Aufgabenliste, die sich weder priorisieren noch schätzen lässt.

User Stories im Planungswerkzeug

Am physischen Board genügt für eine User Story ein Post-it. In einem Werkzeug für agile Planung bekommt sie eine feste Struktur. Aus ihr wird ein Objekt, das sich priorisieren, schätzen und bis in die Produktion verfolgen lässt.

In GitLab gibt es kein eigenes Objekt "User Story". Eine User Story wird dort als Issue angelegt, nach der klassischen Vorlage oder in einem alternativen Format, der Job Story. Ein Issue kann ebenso gut einen Bug oder eine Aufgabe beschreiben, und jedes Team legt seine eigenen Konventionen fest. Das Scrum-Tutorial schlägt zum Beispiel vor, die Arten über Scoped Labels zu unterscheiden (type::story, type::bug, type::maintenance).

Die von Alan Klement formulierte Job Story stellt die Situation in den Mittelpunkt statt der Rolle: "Wenn ich eine neue App entdecke, möchte ich schnell ein Konto anlegen, damit ich sie sofort nutzen kann." Von einer konkreten Situation statt von einer allgemeinen Rolle auszugehen, hilft oft, die tatsächliche Motivation der Nutzer(innen) zu erfassen und den erwarteten Nutzen zu schärfen. Genau dieses Format bevorzugt auch das GitLab-Tutorial zur Umsetzung von Scrum mit GitLab.

GitLab gliedert diese Umgebung in mehrere sich ergänzende Funktionen: Epics, die Issues mit demselben Ziel bündeln, das Feld für die Gewichtung (Weight), das den geschätzten Aufwand beziffert und die Story Points ersetzt, Iterationen, die die Sprints strukturieren, und Issue Boards, auf denen jedes Issue von "bereit für die Entwicklung" bis "erledigt" voranschreitet. Einige dieser Funktionen sind Teil von GitLab Premium und GitLab Ultimate.

Mit aktiviertem automatischem Übertrag (Roll-over) wandert jedes nicht abgeschlossene Issue am Sprintende in die nächste Iteration, sodass keine User Story unterwegs verloren geht.

Bei GitLab nutzen die Teams solche User Stories, um den tatsächlichen Nutzen der priorisierten Funktionen im Blick zu behalten. Wer Planung, Entwicklung und Projektverfolgung in einer einheitlichen Umgebung bündelt, befreit Team-Meetings vom Verwalten verstreuter Werkzeuge und richtet sie wieder auf das Wesentliche aus: Entscheidungen.

Das Wichtigste im Überblick

Eine User Story ist eine Erzählung aus Sicht der Nutzer(innen), die eine Anforderung und ihren Nutzen formuliert und das Gespräch eröffnet, aus dem eine Funktion entsteht. Die Vorlage "Als … möchte ich … damit …" hilft beim Formulieren. Die INVEST-Kriterien prüfen die Qualität, und die Akzeptanzkriterien legen fest, wann die Anforderung erfüllt ist. Alles Weitere ergibt sich in der Praxis: beim Schreiben, beim Zerlegen zu großer User Stories und im fortlaufenden Austausch mit den Stakeholdern.

Ist das Team bereit, vom Post-it zum werkzeuggestützten Backlog zu wechseln, unterstützen eine passende agile Methodik und eine Plattform wie GitLab, die Planung, Entwicklung und Auslieferung an einem Ort vereint, bei jedem Schritt.

→ GitLab Ultimate kostenlos testen

FAQ zur User Story

Wer schreibt User Stories?

Meist liegt das beim Product Owner, der den erwarteten Nutzen und die Priorität der Anforderungen am besten kennt. Eine gute User Story entsteht aber gemeinsam: Entwickler(innen) und Tester(innen) ergänzen sie im Backlog Refinement, und grundsätzlich kann jedes Teammitglied eine User Story vorschlagen.

Was unterscheidet eine User Story von einem Use Case?

Ein Use Case (Anwendungsfall) beschreibt in einem ausführlichen Dokument alle Interaktionen zwischen Nutzer(innen) und System im Detail, einschließlich der Fehlerfälle. Die User Story bleibt bewusst kurz, konzentriert sich auf eine Anforderung und ihren Nutzen und überlässt den Rest dem Gespräch und den Akzeptanzkriterien.

Wie viele Akzeptanzkriterien braucht eine User Story?

Eine feste Regel gibt es nicht, aber drei bis fünf Kriterien reichen meist, um Unklarheiten auszuräumen. Wer zehn aufreiht, hat vermutlich eine zu große User Story vor sich, die sich besser aufteilen lässt.

Muss eine User Story in einen Sprint passen?

Ja, und zwar mit deutlichem Spielraum: Das Kriterium "Small" aus INVEST spricht von einigen Tagen Arbeit. Eine User Story, die über den Sprint hinausgeht, sollte in kleinere User Stories aufgeteilt werden, die jeweils einen Teil des Nutzens liefern.