Leitfaden
Der vollständige Planning-Poker-Leitfaden
Eine konsensbasierte Schätztechnik, die in agilen Teams zum Standard für die Größenbestimmung von Backlog-Items geworden ist. Dieser Leitfaden behandelt, was es ist, woher es kommt, warum es funktioniert und wie ihr eine Session aufsetzt, die tatsächlich konvergiert.
Was ist Planning Poker?
Planning Poker ist eine konsensbasierte Schätztechnik. Jedes Teammitglied wählt verdeckt eine Karte mit seiner Aufwandsschätzung für ein Backlog-Item. Alle decken gleichzeitig auf. Weichen die Schätzungen stark voneinander ab, wird die Lücke diskutiert und das Team stimmt erneut ab.
Der Mechanismus erfüllt einen spezifischen Zweck: Er eliminiert das Anchoring auf die lauteste Stimme. In einer Ad-hoc-Schätzdiskussion zieht die zuerst genannte Zahl — meist von der erfahrensten Person im Raum — jede weitere Schätzung zu sich. Das gleichzeitige Aufdecken macht dieses Anchoring unmöglich.
Planning Poker ist die am weitesten verbreitete Schätztechnik in Scrum und Extreme Programming.
Tiefere Einblicke:
Story Points erklärt · Die Fibonacci-Skala in der agilen Schätzung · Planning Poker für verteilte Teams · Planning Poker vs. Scrum Poker
Woher es kommt
James Grenning erfand Planning Poker 2002. Er beobachtete ein Team, das ein Backlog schätzte, indem es Item für Item Entwickler-Meinungen einsammelte. Stunden später hatten sie nur einen Bruchteil der Arbeit abgedeckt. Grenning griff zu Karteikarten, schrieb Zahlen darauf und machte die Session zu einem simultanen Aufdecken. Er schrieb später den Original-Artikel, der die Technik beschreibt.
Mike Cohn popularisierte sie 2005 in seinem Buch Agile Estimating and Planning, das bis heute die kanonische Referenz für das Sizing von Backlogs in Scrum-Teams ist.
Planning Poker ist eine direkte Vereinfachung von Wideband Delphi, einer Schätzmethode, die Barry Boehm 1981 in seinem Buch Software Engineering Economics beschrieb. Wideband Delphi läuft dieselbe iterative Konvergenzschleife, nutzt aber schriftliche Einreichungen und eine Moderation — Planning Poker bündelt das in eine Kartenrunde.
Warum es funktioniert: Anchoring und Gruppenkonvergenz
Zwei Effekte machen Planning Poker genauer als Ad-hoc-Diskussion:
Eliminierung des Anchorings
Kognitionspsychologen nennen es Anchoring-Bias: numerische Schätzungen werden zu der Zahl gezogen, die als erstes genannt wird. Der Effekt ist seit Tversky und Kahnemans Science-Paper Judgment under Uncertainty (1974) gut dokumentiert. Das simultane Aufdecken eliminiert den Erste-Zahl-Effekt, indem es die erste Zahl entfernt. Jede Schätzung ist unabhängig.
Erzwungene Artikulation von Uneinigkeit
Wenn zwei Teammitglieder 3 und 13 auf dieselbe Story setzen, ist die Lücke konkret und nicht wegzuwischen. Die natürliche Folgefrage — "Was denkt jede(r) von euch gerade?" — bringt eine ungesagte Annahme, fehlenden Kontext oder einen Definitions-Mismatch zutage, der sonst mit der falschen Schätzung weitergereicht worden wäre. Die Schätzung verbessert sich, weil sich der Input verbessert.
Die zugrundeliegende Methode (Wideband Delphi) wird seit den 1970ern formal untersucht. Iterierte Gruppenschätzungen konvergieren auf Werte, die deutlich genauer sind als die erste Einschätzung jedes einzelnen Experten — ein Ergebnis, das in mehreren Replikationen bestätigt wurde.
Ablauf einer Session
In Ace-The-Backlog in drei Schritten:
- Backlog einfügen. Tickets eine pro Zeile eintragen. JIRA-Keys, Ticket-Beschreibungen oder Kurzzusammenfassungen funktionieren alle. Bis zu 200 Items pro Session.
- Rollen und Skalen konfigurieren. Bis zu fünf Stimmrollen pro Session, jede mit eigener Skala. Häufige Kombinationen: Dev (Fibonacci) + QA (Fibonacci) + Design (T-Shirt) auf demselben Ticket — erfasst das vollständige Aufwandsbild, nicht nur Engineering.
- Room-Link teilen. Alle treten live im Browser bei, kein Account nötig. Abstimmung läuft pro Rolle pro Ticket: Dev stimmt zuerst ab, Aufdecken, Diskussion, einlocken. Dann QA auf demselben Ticket. Dann Design. Nächstes Ticket.
Eine Session mit 10 bis 20 Tickets dauert typischerweise 30 bis 60 Minuten, je nachdem wie viel Diskussion jede Uneinigkeit auslöst. Räume werden nach 24 Stunden automatisch gelöscht.
Schätzskalen
Die meisten Teams nutzen Fibonacci-Story-Points (1, 2, 3, 5, 8, 13, 21) als Standard. Die wachsenden Abstände sind bewusst gewählt — sie spiegeln eine reale Eigenschaft menschlichen Schätzens wider: Je größer die Arbeit, desto weniger präzise kann eine einzelne Zahl sein. Eine "13" trägt das implizite "das ist grob; wir haben nicht genug Auflösung, um es von einer 21 zu unterscheiden" mit sich.
Andere Skalen funktionieren in spezifischen Kontexten:
- Stunden (1h bis 40h) — für Aufgaben unter ein bis zwei Tagen, bei denen das Team gemeinsame Maßstäbe hat ("ein CRUD-Endpoint mit Tests ist 4h"). Konkret genug, um einen Tag drumherum zu planen, schwammig genug, um kleine Überraschungen aufzufangen.
- Tage (0,5d bis 13d) — für Meilenstein-Planung, nicht einzelne Stories. Nützlich für Roadmaps.
- T-Shirt-Größen (XS bis XXL) — für frühe grobe Größenabschätzung, bevor Stories aufgeteilt sind. Weniger Commitment als eine Zahl; hilft beim Priorisieren, ohne Präzision zu behaupten.
In diesem Tool wählt jede Stimmrolle ihre eigene Skala pro Session — Dev in Fibonacci, Design in T-Shirt-Größen, auf demselben Ticket. Siehe den Fibonacci-Skala-Leitfaden für die Begründung der wachsenden Abstände und Story Points erklärt für die Einheit, in der ihr tatsächlich schätzt.
Häufige Stolpersteine
Anchoring durch "Was hatte jeder beim letzten Mal abgestimmt?"
Die Stimmen der vorigen Runde während der erneuten Abstimmung zu zeigen, torpediert den Mechanismus teilweise. Re-Votes anonym halten und erst beim nächsten Aufdecken sichtbar machen.
Schätzen im Vakuum
Ein Team, das noch nie eine Story gemeinsam ausgeliefert hat, hat kein geteiltes Verständnis, was eine "5" bedeutet. In den ersten drei bis fünf Sprints kalibrieren, indem ihr euch an einer bekannten Referenz-Story orientiert ("das haben wir in drei Tagen geliefert; das ist unsere 5").
Eine Person dominiert die Post-Reveal-Diskussion
Planning Poker ist gut darin, die Lücke aufzudecken, weniger gut darin, sie zu schließen. Ein Facilitator, der explizit die Ausreißer-Stimmen — nicht die erfahrenste Person — zuerst zu Wort kommen lässt, ist der praktische Fix.
13+ Stories schätzen
Alles, was konstant bei 13 oder höher landet, ist zu groß für eine genaue Schätzung und vermutlich zu groß für einen Sprint. Aufteilen.
FAQ
- Wie viele Personen sollten an einer Planning-Poker-Session teilnehmen?
- Drei bis sieben Stimmberechtigte sind ideal. Unter drei verliert ihr den Gruppenkonvergenz-Effekt; über sieben werden Sessions lang und Ausreißer-Diskussionen zerfallen. Stakeholder und Zuhörer können ohne Stimmrecht beitreten.
- Geht Planning Poker auch außerhalb von Scrum?
- Ja. Planning Poker ist eine allgemeine Konsens-Schätztechnik. Scrum ist der häufigste Kontext, aber Kanban-Teams, Extreme-Programming-Teams und Product-Management-Gruppen nutzen es ebenso.
- Was passiert, wenn alle in der ersten Runde gleich abstimmen?
- Fertig. Wert einlocken, weiter zum nächsten Ticket. Konvergenz in der ersten Runde ist das Ziel, nicht ein Fehlerzustand.
- Wie lange sollte eine Planning-Poker-Session dauern?
- Plant zwei bis vier Minuten pro Ticket für ein gut verfeinertes Backlog. Eine 15-Ticket-Session landet typischerweise bei 30 bis 60 Minuten. Länger heißt: das Backlog ist nicht bereit — vage Stories oder fehlende Akzeptanzkriterien — und der Fix liegt im Input, nicht in der Session.
- Sollte der Product Owner mitstimmen?
- Generell nein. Der Product Owner liefert Kontext und beantwortet Fragen, stimmt aber nicht über Aufwand ab. Stimmberechtigt sind die, die die Arbeit machen werden.
Bereit für eine Session?
Öffne das Tool und füge dein Backlog ein. Kein Account, keine Anmeldung. Sessions werden nach 24 Stunden automatisch gelöscht.
Planning-Poker-Session starten