User Stories
Eine User Story ist ein kleines Stück Funktionalität, das aus Sicht der Nutzer:innen auf einer Karte beschrieben wird und das ein Team mit seinem Kunden oder Product Owner durchspricht und vereinbart. Die Praxis stammt aus dem Extreme Programming, wo Kent Beck und Kolleg:innen sie Ende der 1990er-Jahre einführten; die Agile Alliance datiert die Rolle-Funktion-Nutzen-Vorlage und Ron Jeffries' Formel „Card, Conversation, Confirmation“ auf 2001 und Bill Wakes INVEST-Checkliste auf 2003. Als Workshop bringt eine Story-Writing-Session Product Owner und Team zusammen, um die Karten zu schreiben, sie zu besprechen und zu vereinbaren, wie bei jeder bestätigt wird, dass sie fertig ist.
Moderationsablauf
- 1
Benenne das Ziel oder Feature, um das es in der Session geht. Listet gemeinsam die beteiligten Nutzerrollen auf und was jede erreichen will.
8 Min. - 2
Alle schreiben still Story-Karten, ein Bedürfnis pro Karte, in der Form Rolle-Funktion-Nutzen. Hängt sie für alle sichtbar auf und entfernt Dopplungen.
10 Min. - 3
Nehmt euch die Karten einzeln vor, die wichtigste zuerst. Das Team befragt den Product Owner, bis der Umfang jeder Story klar ist, und schreibt die Karte bei Bedarf neu.
15 Min. - 4
Ergänzt bei jeder besprochenen Story Akzeptanzkriterien, damit klar ist, wie „fertig“ bestätigt wird.
10 Min. - 5
Prüft die Stories anhand von INVEST und teilt die zu großen auf. Parkt Fragen, die niemand im Raum beantworten kann, jeweils mit einer namentlich verantwortlichen Person.
7 Min. - 6
Der Product Owner ordnet die Karten in Lieferreihenfolge an. Vereinbart, welche Stories bereit für die nächste Iteration sind und welche noch mehr Gespräch brauchen.
5 Min.
Tipps
Behandle die Karte als Erinnerung daran, ein Gespräch zu führen, nicht als Spezifikation; wird es still im Raum und beginnen die Leute, an Sätzen zu feilen, bringe sie zurück ins Gespräch.
Schreibt Stories mit den Menschen, die sie bauen und testen werden, denn eine fertig übergebene Story überspringt das gemeinsame Verständnis, das sie nützlich macht.
Lässt sich eine Story nicht teilen, suche nach den Nahtstellen: unterschiedliche Nutzerrollen, Schritte in einem Ablauf, Datenvarianten oder der einfache Fall vor den Ausnahmen.
Typische Stolperfallen
Die geschriebene Karte als Anforderung behandeln und das Gespräch auslassen, sodass das Team baut, was der Satz sagt, und nicht, was die Nutzer:innen brauchen
Der Product Owner schreibt alle Stories vorab allein – das macht die Session zur Vorlesestunde und nimmt ihr das gemeinsame Verständnis
Den Nutzen-Teil leer oder allgemein lassen, sodass niemand beurteilen kann, ob eine kleinere oder andere Lösung den Nutzer:innen ebenso gut dienen würde
Stories für Architekturschichten oder Komponenten schreiben statt für Ausschnitte, die Nutzer:innen sehen können – das verzögert alles Nutzbare, bis jede Schicht fertig ist
Das ganze Backlog gleich tief ausarbeiten – das verschwendet Aufwand für Stories, die sich ändern oder nie gebaut werden
Variationen
Bei einem neuen Produkt beginnst du mit einer Story-Mapping-Session, um die Reise der Nutzer:innen auszulegen, und schreibst dann Stories für den ersten Ausschnitt. Bei Stories mit kniffligen Geschäftsregeln schließt du Example Mapping an, um Regeln in konkrete Beispiele zu übersetzen, bevor die Story in einen Sprint geht. Remote-Teams schreiben Karten auf einem gemeinsamen Board oder direkt ins Backlog-Tool, während eine Person den Bildschirm teilt; lasst für den Gesprächsschritt die Kameras an. Manche Teams bevorzugen Job Stories, die statt einer Nutzerrolle die Situation und die Motivation beschreiben.
Einsatzbereiche
Wann einsetzen
Ein Team beginnt ein Produkt oder Feature und braucht ein erstes Backlog, das Fachseite und Entwicklung gleichermaßen verstehen
Anforderungen kommen als lange Dokumente an, und das Team entdeckt während der Entwicklung immer wieder Missverständnisse
Ein Epic ist zu groß, um es zu planen, und muss in Stücke geschnitten werden, die jeweils etwas liefern, das Nutzer:innen verwenden können
Ein neuer Product Owner und das Team müssen eine gemeinsame Art finden, Arbeit zu beschreiben
Stakeholder beschreiben Lösungen, und das Team muss zurück zu der Frage, wer was braucht und warum
Wann nicht einsetzen
Die gesamte User Journey ist noch unklar; führt zuerst Story Mapping durch, damit die Stories eine Struktur haben, in die sie sich einfügen
Die Arbeit ist rein technisch und hat kein für Nutzer:innen sichtbares Ergebnis; beschreibt sie als einfache Aufgabe, statt ihr eine Nutzerrolle überzustülpen
Die Stories existieren, und offen sind die detaillierten Geschäftsregeln; nutze Example Mapping
Das Team muss vorhandene Einträge nur ordnen und schätzen; das ist eine Session für Backlog Refinement oder Planning Poker
Weder Product Owner noch eine Vertretung des Kunden kann teilnehmen; den Schritten Gespräch und Bestätigung fehlt dann das Gegenüber, mit dem etwas vereinbart wird
Ähnliche Methoden
Weiterführende Artikel
Häufig gestellte Fragen
Was sind User Stories?▾
User Stories sind kurze Beschreibungen von Funktionalität aus Sicht der Nutzer:innen, eine pro Karte, die ein Team mit seinem Kunden oder Product Owner vereinbart. Jede Karte steht für ein Gespräch über das Bedürfnis und kommt mit vereinbarten Kriterien, anhand derer bestätigt wird, dass sie fertig ist. Die Praxis hat ihren Ursprung im Extreme Programming.
Wie sieht eine User Story aus?▾
Die gängige Vorlage nennt eine Rolle, eine Funktion und einen Nutzen: Als bestimmte Art von Nutzer:in möchte ich etwas tun, damit ich etwas davon habe. Die Vorlage ist eine Hilfe, keine Regel. Entscheidend ist, dass die Karte benennt, wer was braucht und warum – so knapp, dass es auf eine Karteikarte passt.
Was bedeuten Card, Conversation, Confirmation?▾
Das ist Ron Jeffries' Zusammenfassung dessen, woraus eine Story besteht. Die Karte (Card) ist die kurze schriftliche Erinnerung, das Gespräch (Conversation) ist die Diskussion, in der Team und Product Owner die Details klären, und die Bestätigung (Confirmation) ist der Satz an Akzeptanzkriterien, der zeigt, dass die Story abgeschlossen ist.
Was ist INVEST?▾
INVEST ist Bill Wakes Checkliste für die Qualität von Stories: independent, negotiable, valuable, estimable, small und testable – also unabhängig, verhandelbar, wertvoll, schätzbar, klein und testbar. Teams nutzen sie in einer Story-Writing- oder Refinement-Session, um Stories zu erkennen, die zu groß, zu vage oder an andere Stories gebunden sind, und um zu entscheiden, welche aufgeteilt werden.
Sind User Stories Teil von Scrum?▾
Nein. Der Scrum Guide spricht von Product-Backlog-Einträgen und erwähnt User Stories nicht. Sie stammen aus dem Extreme Programming und werden von Scrum-Teams häufig als ein praktisches Format für Backlog-Einträge verwendet.
Plane deinen nächsten Workshop mit KI
Workshop Weaver kombiniert Methoden wie User Stories zu einer vollständigen, zeitlich geplanten Agenda. In Minuten.
Kostenlos testenMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Extreme Programming (Kent Beck and colleagues); Ron Jeffries (Card, Conversation, Confirmation); Bill Wake (INVEST).