Agile-Leitfaden · Agile Praktiken
User Stories: So schreiben Sie sie, mit Vorlagen und Beispielen
Eine User Story ist eine kurze, verständliche Beschreibung dessen, was ein Nutzer braucht, aus seiner Sicht formuliert. Sie hält fest, wer etwas möchte, was und warum, und dient als Platzhalter für ein Gespräch über die Details statt als vollständige Spezifikation.
Das Wichtigste in Kürze
- Eine User Story beschreibt, wer etwas braucht, was er braucht und warum.
- Akzeptanzkriterien machen jede Story testbar; die Definition of Done gilt für alle Stories.
- Prüfen Sie die Qualität mit INVEST und teilen Sie Stories auf, die nicht in einen Sprint passen.
- Stories sind Ausgangspunkt für ein Gespräch, keine vollständige Spezifikation.
Die User-Story-Vorlage
Das gängigste Format lautet: Als [Art des Nutzers] möchte ich [Ziel] damit [Nutzen].
- Wer: ein bestimmter Nutzer oder eine Rolle, nicht „das System“.
- Was: das Ziel oder die Fähigkeit, die benötigt wird, nicht die technische Lösung.
- Warum: der Nutzen, der dem Team hilft, den einfachsten Weg zur Umsetzung zu finden.
Viele Teams beschreiben eine Story mit den drei Cs: der Karte (die kurze schriftliche Story), dem Conversation (Gespräch) (das Gespräch, das die Details klärt) und der Confirmation (Bestätigung) (die Akzeptanzkriterien, die zeigen, dass sie erledigt ist).
Akzeptanzkriterien
Akzeptanzkriterien sind die Bedingungen, die eine Story erfüllen muss, um abgenommen zu werden. Sie machen die Story testbar und verringern Missverständnisse. Zwei gängige Formen:
- Checkliste: „Die Buchung zeigt Uhrzeit und Ort des Kurses“; „Das Mitglied erhält eine Bestätigungs-E-Mail“.
- Given-When-Then: „Gegeben ein Kurs hat freie Plätze, wenn ein Mitglied auf Buchen tippt, dann wird ein Platz reserviert und die Zahl der freien Plätze sinkt um eins.“
Die INVEST-Checkliste
| Buchstabe | Bedeutung | Leitfrage |
|---|---|---|
| I | Independent (unabhängig) | Lässt sie sich liefern, ohne auf eine andere Story zu warten? |
| N | Negotiable (verhandelbar) | Sind die Details offen für Diskussion statt festgelegt? |
| V | Valuable (wertvoll) | Liefert sie einem Nutzer oder dem Unternehmen einen Mehrwert? |
| E | Estimable (schätzbar) | Versteht das Team sie gut genug, um sie zu schätzen? |
| S | Small (klein) | Lässt sie sich innerhalb eines Sprints abschließen? |
| T | Testable (testbar) | Gibt es klare Akzeptanzkriterien? |
So schreiben Sie eine User Story, Schritt für Schritt
- Bestimmen Sie den Nutzer und sein Ziel, idealerweise auf Basis von Recherche oder echtem Feedback.
- Schreiben Sie die Story nach der Vorlage und beschränken Sie sie auf ein bis zwei Sätze.
- Ergänzen Sie drei bis sechs Akzeptanzkriterien.
- Besprechen Sie sie mit dem Team im Backlog Refinement und passen Sie sie an.
- Prüfen Sie sie anhand von INVEST; teilen Sie sie auf, wenn sie zu groß ist.
- Schätzen Sie sie, zum Beispiel mit Story Points.
- Ordnen Sie sie im Product Backlog nach Wert, Risiko und Abhängigkeiten.
Beispiele: schwach und verbessert
| Schwache Story | Verbesserte Story |
|---|---|
| Als Nutzer möchte ich eine Datenbanktabelle für Buchungen. | Als Mitglied möchte ich einen Kurs buchen, damit mein Platz reserviert ist. |
| Als System möchte ich E-Mails versenden. | Als Mitglied möchte ich eine Buchungsbestätigung per E-Mail, damit ich einen Nachweis über meinen Kurs habe. |
| Als Nutzer möchte ich, dass die Website schnell ist. | Als mobiler Nutzer möchte ich, dass der Kursplan in unter zwei Sekunden lädt, damit ich unterwegs buchen kann. |
| Als Administrator möchte ich ein Berichtsmodul mit 15 Berichten. | Als Studioleiter möchte ich die wöchentliche Teilnehmerzahl pro Kurs sehen, damit ich den Stundenplan anpassen kann. |
Vollständiges Beispiel: Als Mitglied möchte ich mich auf eine Warteliste setzen, wenn ein Kurs ausgebucht ist, damit ich einen Platz bekomme, falls jemand absagt. Akzeptanzkriterien: Die Schaltfläche „Auf Warteliste setzen“ erscheint nur, wenn ein Kurs ausgebucht ist; das Mitglied sieht seine Position; wird ein Platz frei, erhält die erste Person per E-Mail ein Angebot und hat zwei Stunden Zeit, es anzunehmen.
Häufige Fehler
- Technische Aufgaben schreiben, die als Stories getarnt sind.
- Stories, die so groß sind, dass sie mehrere Sprints umfassen; behandeln Sie diese als Epics und teilen Sie sie auf.
- Kein „damit“-Teil, wodurch das eigentliche Bedürfnis verborgen bleibt.
- Die Story als Vertrag behandeln, statt damit ein Gespräch anzustoßen.
- Fehlende oder vage Akzeptanzkriterien, die zu Nacharbeit führen.
- Jede Story nach der Vorlage schreiben, auch wenn ein einfacher Satz klarer wäre.
Kostenlose Vorlagen zu diesem Thema
Häufig gestellte Fragen
Was ist eine User Story in Agile?
Eine kurze Beschreibung eines Nutzerbedürfnisses aus Sicht des Nutzers, die das Team in funktionsfähige Funktionalität umsetzt.
Wie ist eine User Story aufgebaut?
Als [Art des Nutzers] möchte ich [Ziel], damit [Nutzen].
Wer schreibt User Stories?
Jeder kann sie schreiben, aber meist ist der Product Owner dafür verantwortlich, dass sie klar formuliert und im Backlog geordnet sind.
Sind User Stories Teil von Scrum?
Nein. Der Scrum Guide spricht von Product-Backlog-Einträgen; User Stories sind eine verbreitete Art, sie zu formulieren.
Was sind Akzeptanzkriterien bei User Stories?
Konkrete, prüfbare Bedingungen, die eine Story erfüllen muss, um abgenommen zu werden, oft als Checkliste oder im Given-When-Then-Format formuliert.
Wie klein sollte eine User Story sein?
Klein genug, um innerhalb eines Sprints fertig zu werden, idealerweise innerhalb weniger Tage.
Wofür steht INVEST bei User Stories?
Independent, Negotiable, Valuable, Estimable, Small und Testable (unabhängig, verhandelbar, wertvoll, schätzbar, klein und testbar).
Was ist der Unterschied zwischen einer User Story und einer Anforderung?
Eine klassische Anforderung legt detailliert fest, was das System leisten muss; eine User Story beschreibt ein Bedürfnis und lädt zum Gespräch ein, um die Details zu vereinbaren. Siehe Projektanforderungen.
Was ist der Unterschied zwischen einer User Story und einem Epic?
Ein Epic ist ein großes Arbeitspaket aus vielen Stories; eine Story passt in einen einzigen Sprint.
Wie schätzt man User Stories?
Die meisten Teams nutzen relative Schätzungen wie Story Points oder T-Shirt-Größen, die das Team gemeinsam festlegt.
Lassen sich User Stories auch außerhalb der Softwareentwicklung einsetzen?
Ja. Marketing- und andere Teams schreiben Stories wie „Als potenzieller Kunde möchte ich einen Preisvergleich, damit ich einen Tarif wählen kann“; siehe Agiles Marketing.