User Stories (mit Akzeptanzkriterien)
Beschreiben, was gebaut werden soll, als kleine, testbare Bedürfnisse aus Sicht der Nutzenden, damit das Team das Richtige baut und weiß, wann es fertig ist.
- Zeit
- 45 Min.
- Personen
- 3–6
- Art der Arbeit
- Planen
Kurz gesagt
Eine User Story ist eine kurze Aussage über ein Bedürfnis von Nutzenden in der Form „Als [Nutzer] brauche ich [etwas], damit [Grund]“, mit Akzeptanzkriterien, die festlegen, wann sie erledigt ist. Dafür bei der Forschung beginnen, verwandte Stories zu Epics bündeln, große Stories teilen und die Kriterien mit denen vereinbaren, die bauen und testen.
Worum es geht
Eine User Story beschreibt ein Stück Arbeit aus Sicht der Person, die es nutzen wird, statt als technische Aufgabe. Sie hat drei Teile: wer die Nutzerin oder der Nutzer ist, was gebraucht wird und warum. Der Damit-Teil zählt am meisten, denn er sagt dem Team, welches Problem die Arbeit löst, und lässt Raum, einen besseren Lösungsweg vorzuschlagen. Jede Story trägt Akzeptanzkriterien: eine kurze Liste von Bedingungen, die erfüllt sein müssen, damit die Story als erledigt gilt.
User Stories stammen aus der agilen Softwarepraxis und wurden Ende der 1990er-Jahre erstmals im Extreme Programming eingesetzt. Heute sind sie in digitalen Serviceteams Standard, auch in der Verwaltung. Das GOV.UK Service Manual verwendet die Formulierung „I need“ (ich brauche) statt „I want“ (ich möchte), um den Fokus auf echte Bedürfnisse zu legen. Große Stories, die ein ganzes Ziel abdecken, heißen Epics und werden in kleinere Stories zerlegt, die sich in kurzer Zeit bauen und testen lassen. Im Arbeitsblatt werden Nutzer, Bedürfnis, Grund, Akzeptanzkriterien, das zugehörige Epic und der Beleg dahinter festgehalten.
Wann sie passt
Geeignet, wenn
- Wenn Forschung und Designarbeit abgeschlossen sind und daraus eine Liste von Arbeit werden soll, die ein Umsetzungsteam bauen kann.
- Wenn ein Anforderungsdokument lang und technisch ist und niemand sagen kann, welche Teile für Nutzende am wichtigsten sind.
- Wenn das erste Release eines neuen Service geplant wird und vereinbart werden muss, was dazugehört und was warten kann.
- Wenn Fach-, Politik- und Technikteams denselben Service mit unterschiedlichen Worten beschreiben und sich immer wieder missverstehen.
- Wenn klare Bedingungen für Tests gebraucht werden, damit alle sich einig sind, wann eine Funktion fertig ist.
Ungeeignet, wenn
- Wenn noch unklar ist, wer die Nutzenden sind und was sie brauchen. Zuerst forschen, sonst beschreiben die Stories Vermutungen.
- Wenn die Arbeit rein technisch ist und sich für Nutzende nichts ändert, etwa ein Datenbank-Upgrade. Eine schlichte Aufgabenbeschreibung ist klarer.
- Wenn noch sehr unterschiedliche Ideen erkundet werden. Stories legen Details zu früh fest; zuerst ein Storyboard oder einen Prototyp nutzen.
Was es braucht
- Zeit
- Etwa 45 Minuten, um die Stories für ein Epic zu entwerfen und zu prüfen; mehr für einen ganzen Service.
- Personen
- 3 bis 6 Personen: eine Produkt- oder Serviceverantwortliche, jemand aus der Forschung und mindestens eine Person, die baut, und eine, die testet.
- Material
- Forschungsergebnisse oder eine Experience Map, Karteikarten oder ein gemeinsames Board und eine einfache Vorlage mit den sechs Feldern des Arbeitsblatts.
So läuft es ab
Schritt 1: Beim Ziel der Nutzenden beginnen
Das übergeordnete Ziel einer Nutzergruppe oben auf das Board schreiben, zum Beispiel „ein Mitglied beantragt eine Altersrente“. Daraus wird das Epic. Die passende Forschung, etwa Zitate, eine Experience Map oder ein Point-of-View-Statement, daneben anheften, damit die Stories mit Belegen verbunden bleiben.
Schritt 2: Die Nutzenden genau benennen
Die Arten von Nutzenden auflisten, die an diesem Ziel beteiligt sind, in einfachen Worten: „ein Mitglied, das dieses Jahr in Rente geht“, „der Arbeitgeber eines Mitglieds“, „eine Sachbearbeiterin für Renten“. „Als Nutzer“ und „als System“ vermeiden; sie verdecken, wessen Bedürfnis es ist. Auch Beschäftigte sind Nutzende und bekommen eigene Stories.
Schritt 3: Die Stories entwerfen
Jede Person schreibt Stories auf getrennte Karten in der Form „Als … brauche ich …, damit …“. Das Bedürfnis in den Worten der Nutzenden formulieren, nicht als Bildschirm oder Schaltfläche: „Ich muss wissen, welche Unterlagen ich schicken soll“ statt „Ich brauche eine Seite zum Hochladen von Dokumenten“. Ein Bedürfnis pro Karte anstreben.
Schritt 4: Den Damit-Teil prüfen
Jede Karte laut vorlesen und fragen, ob der Grund echt und konkret ist. „Damit ich den Antrag stellen kann“ fügt nichts hinzu. „Damit sich meine erste Zahlung nicht verzögert“ sagt dem Team, wie Erfolg aussieht. Kann niemand sagen, warum die Nutzenden es brauchen, die Karte herausnehmen oder als zu prüfende Annahme markieren.
Schritt 5: Große Stories teilen
Würde ein Team mehr als ein paar Tage brauchen, um eine Story zu bauen und zu testen, sie teilen. Gute Wege sind die Teilung nach Nutzertyp, nach Schritt in der Journey, nach einfachen und komplexen Fällen oder zuerst der Hauptpfad und später die Ausnahmen. Die geteilten Stories unter demselben Epic behalten.
Schritt 6: Akzeptanzkriterien schreiben
Für jede Story drei bis sechs Bedingungen vereinbaren, die erfüllt sein müssen, wenn sie erledigt ist, so formuliert, dass eine Testerin sie prüfen kann. Ein nützliches Muster ist „Angenommen [Situation], wenn [Handlung], dann [Ergebnis]“. Auch die Fehlerpfade aufnehmen, etwa ein fehlendes Dokument oder eine falsche Nummer, nicht nur den Hauptpfad.
Schritt 7: Ordnen und festhalten
Die Stories unter dem Epic in der Reihenfolge anordnen, in der Nutzende ihnen begegnen, und dann markieren, welche für das erste Release nötig sind. Jede Story mit Beleg und Kriterien im Backlog des Teams festhalten und vereinbaren, wer die Stories vor Baubeginn mit dem Forschungsteam prüft.
Praxisbeispiel
Eine öffentliche Pensionskasse erhielt rund 3.400 Rentenanträge im Monat, fast alle auf Papier. Die Bearbeitung dauerte im Schnitt 47 Tage, und 38 % der Anträge gingen mindestens einmal an das Mitglied zurück, weil Angaben fehlten oder falsch waren. Die Kasse plante einen Online-Service und hatte ein 400-seitiges Anforderungsdokument, mit dem das Umsetzungsteam kaum arbeiten konnte.
Fünf Personen trafen sich für 45 Minuten: die Serviceverantwortliche, ein User Researcher, eine Sachbearbeiterin für Renten, ein Entwickler und eine Testerin. Sie nahmen das Epic „ein Mitglied beantragt eine Altersrente“ und legten Interviewzitate und die Experience Map daneben.
Sie listeten vier Nutzende auf: ein Mitglied, das dieses Jahr in Rente geht, der Arbeitgeber eines Mitglieds, eine Sachbearbeiterin für Renten und ein bevollmächtigter Angehöriger eines Mitglieds. Der erste Entwurf ergab 26 Story-Karten.
Die Prüfung des Damit-Teils entfernte vier Karten, die nur den Schritt wiederholten. Außerdem wurde aus „Als Mitglied muss ich meine Dienstzeitbescheinigung hochladen“ die Story „Als Mitglied, das dieses Jahr in Rente geht, muss ich wissen, dass mein Arbeitgeber meine Beschäftigungszeiten bereits bestätigt hat, damit ich nicht selbst eine Bescheinigung beschaffen muss“.
Die Story zur Rentenberechnung war zu groß. Das Team teilte sie in drei: Mitglieder mit einem Arbeitgeber, Mitglieder mit mehreren Arbeitgebern und Mitglieder mit Beitragslücken, und markierte nur die erste für Release eins.
Zu den Akzeptanzkriterien der Story über die Beschäftigungszeiten gehörten „Angenommen, der Arbeitgeber hat die Zeiten bestätigt, wenn sich das Mitglied anmeldet, dann werden die Zeiten angezeigt und können bestätigt werden“ und „Angenommen, die Zeiten fehlen, wenn sich das Mitglied anmeldet, dann sieht es, an wen es sich wenden kann, und der Fall wird für eine Sachbearbeitung markiert“.
Das fertige Backlog für das Epic enthielt 18 Stories, 11 davon für das erste Release markiert. Das Team vereinbarte vor dem ersten Sprint eine Prüfung mit dem Researcher.
Zur VeranschaulichungTipps und typische Fehler
Tipps
- Das Bedürfnis als etwas formulieren, das die Nutzenden erreichen wollen, nicht als Funktion. Das lässt dem Team Raum, eine einfachere Lösung zu finden.
- Stories so klein halten, dass sie sich innerhalb eines Sprints oder einer Woche bauen und testen lassen. Große Stories verstecken Risiken.
- Auch Stories für Beschäftigte schreiben. Sachbearbeitende, die Fälle bearbeiten, haben Bedürfnisse, die den ganzen Service prägen.
- Jede Story mit dem Beleg dahinter verknüpfen, damit alle prüfen können, woher ein Bedürfnis stammt.
Typische Fehler
- Überall „Als Nutzer“ schreiben, was die unterschiedlichen Bedürfnisse verschiedener Menschen verdeckt.
- Aus einer technischen Aufgabe eine Story machen, indem man „Als System“ davorsetzt, was den Sinn des Formats verfehlt.
- Die Akzeptanzkriterien weglassen, sodass Team und Testende jeweils selbst entscheiden, was erledigt bedeutet.
- Das ganze Backlog allein am Schreibtisch schreiben und übergeben, statt es mit dem Team zu entwerfen und zu prüfen.
Was am Ende vorliegt
Am Ende steht ein Epic, zerlegt in kleine User Stories, die jeweils Nutzer, Bedürfnis und Grund benennen, mit Akzeptanzkriterien, einem Verweis auf den Beleg und einer Markierung für das erste Release. Die Stories gehen direkt ins Backlog des Umsetzungsteams. Roadmapping hilft, Epics über die Zeit zu ordnen, und ein Storyboard kann zeigen, wie sich die Stories zu einer Erfahrung fügen.
Häufige Fragen
Warum verwendet GOV.UK in User Stories „I need“ statt „I want“?
„I need“ (ich brauche) legt den Fokus darauf, was Nutzende können müssen, um das Ergebnis zu erreichen, statt auf Vorlieben. Das drängt Teams, nach Belegen zu fragen, dass das Bedürfnis echt ist. Viele Teams außerhalb der Verwaltung schreiben „ich möchte“; der Aufbau der Story bleibt derselbe.
Was ist der Unterschied zwischen einem Epic und einer User Story?
Ein Epic ist ein großes Ziel von Nutzenden, etwa eine Rente zu beantragen, das zu groß ist, um es in einem Zug zu bauen. Eine User Story ist ein kleiner Teil dieses Ziels, den ein Team in wenigen Tagen bauen und testen kann. Ein Epic enthält meist mehrere Stories, manchmal Dutzende.
Wie viele Akzeptanzkriterien sollte eine User Story haben?
Meist drei bis sechs. Weniger können bedeuten, dass die Story vage ist oder Fehlerpfade übersehen wurden. Deutlich mehr bedeuten oft, dass die Story zu groß ist und geteilt werden sollte.
Werkzeugkarte
Das Arbeitsblatt, das das Team ausfüllt, ein Kästchen pro Feld.
- Nutzer
- Bedürfnis
- Damit
- Akzeptanzkriterien
- Epic
- Beleg