Planning Poker (auch Scrum Poker) ist eine kollaborative, konsensbasierte Schätzmethode, die in agilen Frameworks wie Scrum, SAFe, LeSS und Nexus genutzt wird, um den relativen Aufwand und die Komplexität von Arbeitspaketen(meist User Stories) einzuschätzen. Jedes Teammitglied wählt verdeckt eine Karte mit einem Zahlenwert aus – typischerweise nach einer modifizierten Fibonacci-Folge (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100). Nach dem gleichzeitigen Aufdecken diskutiert das Team große Abweichungen, klärt offene Fragen und wiederholt den Vorgang, bis ein tragfähiger Konsens entsteht.
Ziel ist nicht die exakte Zeitvorgabe, sondern ein gemeinsames Verständnis von Komplexität und ein robuster Vergleich der Stories untereinander.
Ursprung und theoretische Basis
Der Ansatz wurde 2002 von James Grenning als „leichteres Wideband-Delphi“ entworfen und durch Mike Cohn in Agile Estimating and Planning populär gemacht. Seine theoretische Basis:
Wideband-Delphi: Ein mehrstufiges Schätzverfahren der 1960er-Jahre, bei dem Expert:innen anonym schätzen, Ergebnisse vergleichen und erneut schätzen, bis sich ein Konsens abzeichnet.
Game Thinking: Spielerische Elemente – verdeckte Karten, gleichzeitiges Aufdecken – verhindern Ankereffekte und fördern Gleichberechtigung.
Kollektive Intelligenz: Teams treffen belastbarere Entscheidungen, wenn unterschiedliche Perspektiven zunächst unabhängig eingebracht und anschließend gemeinsam reflektiert werden.
Diese Wurzeln machen Planning Poker zu einem strukturierten, aber leichtgewichtigen Werkzeug für iterative Konsensbildung.
Detailliertes Vorgehen und Good Practices
1. Vorbereitung
Definition of Ready sicherstellen: User Stories sind klar beschrieben, Akzeptanzkriterien definiert.
Baseline-Stories festlegen: 2–3 Referenz-Items (z. B. 3, 5 und 8 Punkte) helfen, künftige Stories leichter relativ einzuordnen.
2. Erste Schätzrunde
Product Owner erläutert Ziel und Rahmen der Story, beantwortet Fragen.
Alle Teammitglieder wählen verdeckt eine Karte.
3. Gleichzeitiges Aufdecken
Alle Karten werden zeitgleich aufgedeckt, wodurch Anker-Effekte vermieden werden.
Starke Abweichungen werden sichtbar.
4. High-/Low-Drilldown
Zuerst begründen diejenigen mit den höchsten und niedrigsten Werten ihre Sicht.
Diskussion fokussiert auf Annahmen, Risiken und Abhängigkeiten.
5. Zweite (max. dritte) Runde
Neue Kartenwahl nach geklärter Diskussion.
Stop-Regel: Spätestens nach drei Runden entscheidet das Team – Konsens, Spike/Research oder Story zurück ins Refinement.
6. Retro-Kalibrierung
In Retrospektiven vergleicht das Team Schätzung und tatsächlichen Aufwand.
Skala oder Vorgehen wird bei systematischen Abweichungen angepasst.
Erweiterte Good Practices für erfahrene Scrum Master und Coaches
- Timeboxing: Maximal 2–5 Minuten pro Item; längere Diskussionen führen zu Ermüdung und Verzerrung.
- Risikofokus: Nicht nur technische, sondern auch Abhängigkeits- und Compliance-Risiken thematisieren.
- Wissensangleichung: Bei großen Abweichungen sofort Wissenslücken identifizieren und gezielt schließen (z. B. durch Spike-Tasks).
- Transparenz leben: Alle Ergebnisse dokumentieren und für Reviews und Portfolio-Entscheidungen nutzen.
- Integration mit Value-Methoden: Aufwandsschätzungen mit Wertbetrachtungen wie WSJF (Weighted Shortest Job First) kombinieren.
Anwendung in unterschiedlichen Frameworks
Scrum
Planning Poker ist hier Best Practice, aber nicht vorgeschrieben. Es findet meist im Backlog Refinement statt, damit Sprints nicht von langwierigen Schätzungen blockiert werden. Entscheidend sind saubere Stories, eine klare Moderation durch den Scrum Master und die aktive Rolle des Product Owners zur Klärung offener Fragen.
SAFe (Scaled Agile Framework)
In SAFe bleibt Planning Poker die bevorzugte Teamtechnik für die Schätzung von Stories. Ergebnisse fließen in Program Increment (PI) Planning ein, wo mehrere Teams ihre Velocity abgleichen. SAFe empfiehlt, Aufwand und Business Value zu kombinieren, sodass Schätzungen als Input für WSJF- und Portfolio-Entscheidungen dienen.
LeSS (Large-Scale Scrum)
LeSS verfolgt ein minimalistisches Skalierungsprinzip: ein Product Owner, ein Product Backlog. Teams können Planning Poker nutzen, um Stories unabhängig voneinander zu schätzen. LeSS-Coaches betonen allerdings, dass Schätzung Diskussion und Lernen fördern soll, nicht Kontrolle. Alternative Verfahren (z. B. Estimation Matrix) sind erlaubt – Planning Poker ist Option, nicht Pflicht.
Nexus
Nexus erweitert Scrum um ein Integration Team. Die eigentliche Schätzung findet weiterhin innerhalb der einzelnen Scrum-Teams statt. Planning Poker bleibt dort unverändert, während das Nexus Integration Team vor allem Abhängigkeiten und Risiken zwischen Teams koordiniert.
Typische Fehler und Herausforderungen
- Scheingenauigkeit: Story Points sind relative Werte; die Umrechnung in Stunden führt zu falschen Erwartungen.
- Gruppendenken trotz Methode: Ohne gezieltes Einbinden leiser Stimmen können dominante Meinungen dennoch die Schätzung verzerren.
- Unklare Anforderungen: Stories ohne Definition of Ready führen zu endlosen Diskussionen und inkonsistenten Werten.
- Velocity-Missbrauch: Wenn Velocity als Leistungskennzahl missverstanden wird, geraten Teams in Schätz- und Lieferdruck.
- Fehlende Nachverfolgung: Ohne systematische Retro-Kalibrierung lernen Teams nicht aus Abweichungen.
Praxisbeispiele aus der agilen Welt
Spotify setzt Planning Poker in kleinen, autonomen Squads ein, kombiniert mit Tech Radar und Engineering Health Checks, um technische Risiken früh zu erkennen.
Atlassian berichtet, dass Planning Poker in verteilten Teams die Transparenz steigert, da auch leise Stimmen gleichwertig Gehör finden und Architekturfragen früh sichtbar werden.
ThoughtWorks nutzt Planning Poker nicht nur in Entwicklungsteams, sondern auch in crossfunktionalen Discovery-Workshops, um geschäftliche und technische Komplexität gemeinsam zu beleuchten.
Diese Beispiele zeigen, dass Planning Poker weit über das reine Schätzen hinausgeht: Es ist Kommunikations- und Lerninstrument, das Reife und Selbstorganisation eines Teams fördert.
CALADE-Perspektive
Bei CALADE setzen wir Planning Poker gezielt als Werkzeug für Teamalignment und Lernzyklen ein:
- In Trainings und Workshops wird Planning Poker genutzt, um agile Werte praktisch erfahrbar zu machen.
- In Transformationsprojekten dient es als Einstieg, um Teams an kollaboratives Schätzen und kollektive Verantwortung heranzuführen.
- In Portfolio- und Strategiearbeit kombinieren wir Planning Poker mit Methoden wie Leading & Lagging Indicators oder Living Transformation®, um Aufwand, Business Value und Wirkung konsistent zu verknüpfen.
Wir achten darauf, dass Planning Poker nicht isoliert als „Schätzspiel“ gesehen wird, sondern als Teil eines professionellen Agilitäts- und Lernsystems.
Verwandte Begriffe
· Scrum
· Backlog Refinement
· Story Points
· Velocity
· SAFe
· LeSS
· Nexus
· Living Transformation
← zurück zur Übersicht