Worum es geht
Modul 3 hat das Product Backlog als Artefakt eingeführt — aber nicht, wie man es füllt. Genau das ist jetzt das Thema. Das Handwerkszeug dafür sind User Stories: kurze, aus Nutzersicht formulierte Anforderungen. Wichtig zur Einordnung: User Stories stammen aus dem Extreme Programming (Kent Beck), nicht aus Scrum. Sie sind eine verbreitete Technik im agilen Umfeld — Scrum selbst schreibt sie nicht vor.
Das Product Backlog
Das Product Backlog ist die lebendige, geordnete Liste aller Ideen und Anforderungen. Es ist nach Priorität sortiert: oben die Einträge mit hoher Priorität — fein ausgearbeitet und bereit für den nächsten Sprint —, weiter unten die grob beschriebenen, die erst später dran sind. Priorisiert wird wertorientiert, nach Nutzen, Risiko und Aufwand.
Das Backlog ist nie „fertig”: Im laufenden Refinement werden Einträge kontinuierlich präzisiert, geschätzt und neu sortiert. Und jeder Eintrag ist für alle verständlich und sichtbar — Transparenz ist Voraussetzung dafür, dass das Team gemeinsam die richtigen Dinge zuerst angeht.
Vom groben Thema zur umsetzungsreifen Story
Anforderungen entstehen selten gleich klein und fertig. Sie werden vom Groben zum Feinen zerlegt:
Große Themen werden also so lange in kleinere Einheiten zerlegt, bis sie umsetzbar und wertbringend sind. Der Weg einer Anforderung verläuft dabei von der Idee über das Sammeln und Verfeinern (Refinement) und das Priorisieren bis zu „bereit für den Sprint”.
Die User-Story-Schablone
Das Herzstück ist eine einfache Schablone, die Rolle, Wunsch und Nutzen zusammenbringt:
Als ‹Rolle› möchte ich ‹Wunsch›, um ‹Nutzen› zu erreichen.
Ein Beispiel aus der xbank-Welt: Als Bankberater möchte ich den Kundenstatus auf einen Blick sehen, um Kunden schneller beraten zu können. Die drei Bestandteile beantworten Wer? (Rolle), Was? (Wunsch) und Warum? (Nutzen). Der „um … zu”-Teil ist dabei kein Schmuck, sondern der Kern: Eine gute Story liefert Wert aus Nutzersicht — wer den Nutzen weglässt, beschreibt nur noch eine Funktion.
Gute Stories: INVEST
Ob eine Story taugt, prüft man mit dem Raster INVEST (Bill Wake, 2003) — sechs Kriterien:
| Kriterium | Bedeutung |
|---|---|
| Independent | möglichst unabhängig von anderen Stories |
| Negotiable | verhandelbar — Details entstehen im Gespräch |
| Valuable | wertvoll und nützlich für Nutzer oder Business |
| Estimable | schätzbar — der Aufwand lässt sich einschätzen |
| Small | klein und fokussiert — passt in einen Sprint |
| Testable | testbar — über Akzeptanzkriterien überprüfbar |
Akzeptanzkriterien und Definition of Ready
Akzeptanzkriterien beantworten: Wann ist die Story erfüllt? Ein verbreitetes Muster ist Given / When / Then (Gegeben / Wenn / Dann):
So werden Erwartungen konkret und überprüfbar. Davon zu unterscheiden ist die Definition of Ready — das Gegenstück zur Definition of Done aus Modul 3: Sie legt fest, wann eine Story überhaupt bereit für den Sprint ist (Ziel und Nutzen klar, Akzeptanzkriterien vorhanden, grob geschätzt, Abhängigkeiten bekannt, nötige Informationen verfügbar).
Priorisierung mit MoSCoW
Nicht alles ist gleich wichtig. MoSCoW ordnet Anforderungen in vier Stufen:
| Stufe | Bedeutung |
|---|---|
| Must have | unverzichtbar — ohne geht es nicht |
| Should have | wichtig, hoher Nutzen — aber nicht zwingend für den Start |
| Could have | wünschenswert, nice to have — wenn Zeit und Kapazität es erlauben |
| Won’t have (this time) | diesmal nicht — nicht Teil dieser Lieferung, evtl. später |
Der häufigste Fehler steckt im „W”: Won’t have (this time) bedeutet „nicht in dieser Lieferung”, nicht „nie”. Priorisieren heißt nichts anderes, als das Richtige zuerst zu liefern.
Häufige Missverständnisse
Vier Irrtümer begegnen einem immer wieder. Eine Story ist keine Spezifikation — zu viel Detail erstickt Flexibilität. Sie ist keine Aufgabe — sie beschreibt das Warum, nicht das Wie. Mehr Details machen sie nicht besser — zu große Stories sind schwer zu planen und zu liefern. Und sie wird nicht technisch formuliert, sondern aus Anwendersicht. Richtig verstanden ist eine User Story vor allem eines: eine Gesprächseinladung, die ein gemeinsames Verständnis im Team schafft.
Quiz zum Modul
3 Fragen · bestanden ab 60% richtigen Antworten.
1. Was bedeutet **„Won't have (this time)"** in MoSCoW?
2. Welche Bestandteile hat die **User-Story-Schablone**?
3. Wie verhalten sich **User Stories und Scrum** zueinander?
Bitte alle Fragen beantworten, dann wird der Button aktiv.
Quellen
- Agile Alliance — User Story Template (User Stories aus Extreme Programming, Kent Beck)
- Agile Alliance — INVEST (Bill Wake, 2003)