Worum es geht
Dieses Modul schließt Teil C ab und bringt zwei Werkzeuge zusammen, die im Sprint-Rhythmus eng zusammenarbeiten: das Schätzen der anstehenden Arbeit und die Retrospektive, in der das Team aus dem Sprint lernt. Beide sind keine Selbstzwecke, sondern leben den empirischen Kern aus Modul 3 — Transparenz, Überprüfung, Anpassung. Der Kreislauf: schätzen, liefern, messen, reflektieren, besser schätzen.
Estimation: relativ statt absolut
Der wichtigste Gedanke zuerst: Agile Teams schätzen Größe und Komplexität, nicht Zeit. Statt „diese Aufgabe dauert drei Tage” fragt das Team „wie groß ist sie im Vergleich zu anderen?”. Das nimmt den Schätzungen den Charakter einer verbindlichen Zusage und macht sie ehrlicher.
Die Einheit dafür sind Story Points, meist auf der Fibonacci-Reihe (1, 2, 3, 5, 8, 13, 21 …). Die wachsenden Abstände sind Absicht: Je größer eine Aufgabe, desto größer die Unsicherheit — eine Wahl zwischen 8 und 13 ist ehrlicher als eine Scheinpräzision zwischen 9 und 10. Geschätzt werden Größe, Komplexität, Aufwand und Unsicherheit zusammen, nicht Stunden oder Personentage. Für grobe Einschätzungen sind auch T-Shirt-Größen (S/M/L/XL) gebräuchlich.
Planning Poker
Geschätzt wird gemeinsam, mit Planning Poker: Die Story wird vorgestellt, alle schätzen verdeckt, dann wird gleichzeitig aufgedeckt. Bei Abweichungen erklären die Schätzenden ihre Sicht, danach wird neu geschätzt, bis ein Konsens steht. Das gleichzeitige Aufdecken ist kein Detail, sondern der Kniff: Es verhindert Anchoring — also dass die erste genannte Zahl alle anderen beeinflusst.
Velocity
Die Velocity ist die Zahl der Story Points, die ein Team pro Sprint schafft — ein Erfahrungswert zur Vorhersage, wie viel realistisch in den nächsten Sprint passt. Entscheidend ist, was sie nicht ist: kein Leistungsziel, kein Maßstab für Teamvergleiche, kein Wettbewerb. Sobald Velocity zur Zielvorgabe wird, schätzen Teams, um gut dazustehen — und die Zahl wird wertlos. Begleitend zeigt ein Burndown-Chart die verbleibende Arbeit über den Sprint hinweg.
Retrospektive: aus dem Sprint lernen
Die Retrospektive ist der Sprint-Rückblick aus Modul 3. Ihr Zweck ist klar abgegrenzt: Das Team reflektiert die Zusammenarbeit und die Prozesse — nicht das Produkt. Genau hier wird sie oft mit dem Review verwechselt:
| Sprint Review (Was?) | Retrospektive (Wie?) |
|---|---|
| Betrachtet das Produkt / Increment | Betrachtet Team & Zusammenarbeit |
| Mit den Stakeholdern | Im Team |
| Frage: „Haben wir das Richtige gebaut?” | Frage: „Wie arbeiten wir als Team zusammen?” |
Formate und Ergebnis
Zwei verbreitete Formate: Start / Stop / Continue (Was beginnen wir? Was beenden wir? Was behalten wir bei?) oder die drei Fragen (Was lief gut? Was lief schlecht? Was nehmen wir uns vor?). Wichtig ist das Ergebnis: wenige, konkrete und umsetzbare Verbesserungsmaßnahmen für den nächsten Sprint — keine lange Wunschliste und keine Beschwerdesammlung. Eine Retrospektive ohne konkrete, im nächsten Sprint umgesetzte Maßnahme verfehlt ihren Zweck.
Die Prime Directive
Damit das funktioniert, braucht es einen sicheren Raum. Die Prime Directive von Norm Kerth bringt die Haltung auf den Punkt: Jeder hat unter den gegebenen Umständen, mit dem damaligen Wissen und Können, nach bestem Wissen und Gewissen gehandelt. Offenheit, Ehrlichkeit und Respekt stehen über Schuldzuweisung — gelernt wird aus dem System, nicht gegen Personen.
Der empirische Lernzyklus
Beide Werkzeuge sind zwei Punkte desselben Kreislaufs: Aus einer User Story (Modul 4) wird relativ geschätzt, im Sprint gebaut und geliefert, mit Velocity und Burndown gemessen, in der Retrospektive reflektiert — und die Verbesserungen fließen in den nächsten Durchlauf. So wird das Team mit jedem Sprint besser: besser schätzen, besser liefern, besser zusammenarbeiten. Das ist der empirische Kern aus Modul 3 in der täglichen Praxis.
Häufige Missverständnisse
Vier Irrtümer halten sich hartnäckig. Story Points sind keine Stunden — sie sind relativ (Größe, Komplexität, Aufwand, Unsicherheit). Höhere Velocity heißt nicht „besseres Team” — sie ist ein Erfahrungswert, kein Vergleichsmaß. Die Retrospektive ist keine Zeitverschwendung — ohne sie keine Verbesserung; sie ist der Schlüssel zu einem starken Team. Und Schätzungen sind keine Zusagen oder Deadlines — sie sind Prognosen mit Unsicherheit, keine Garantie.
Quiz zum Modul
3 Fragen · bestanden ab 60% richtigen Antworten.
1. Was schätzen agile Teams mit **Story Points**?
2. Worin unterscheiden sich **Review und Retrospektive**?
3. Was besagt die **„Prime Directive"** einer Retrospektive?
Bitte alle Fragen beantworten, dann wird der Button aktiv.
Quellen
- Agile Alliance — Glossary (Estimation, Velocity, Retrospektive)
- Mike Cohn, Agile Estimating and Planning (Story Points, Planning Poker)
- Norm Kerth, Project Retrospectives (Prime Directive)