Was ist die Planning-Poker-Technik?

Planning Poker ist eine konsensbasierte agile Schätzmethode, die Teams dabei hilft, User Stories mithilfe eines strukturierten Prozesses und offener Diskussion zu bewerten. Sie wird in Scrum-Teams häufig bei der Sprint-Planung und im Backlog-Refinement eingesetzt. Die Kombination aus Anonymität, gleichzeitigem Aufdecken und strukturierter Diskussion macht sie zu einer der wirkungsvollsten Methoden für ehrliche, vom Team getragene Schätzungen.

Der Name leitet sich von den ursprünglich verwendeten physischen Kartendecks ab, die Spielkarten ähneln – heute nutzen die meisten Teams jedoch Online-Tools, die dieselbe Mechanik replizieren, ohne dass alle im selben Raum sein müssen.

Die vier Schritte des Planning Poker

Schritt 1: Die User Story vorlesen

Der Moderator – typischerweise der Scrum Master – stellt dem Team eine User Story vor. Der Product Owner ist anwesend, um Kontext zu geben, Fragen zu beantworten und Akzeptanzkriterien zu klären. In dieser Phase geht es darum sicherzustellen, dass jeder Teilnehmende die Story gut genug versteht, bevor die eigentliche Schätzung beginnt.

Dieser Schritt ist oft der Ort, an dem wertvolle Vor-Schätz-Diskussionen stattfinden. Teammitglieder können nach Sonderfällen, Abhängigkeiten oder technischen Einschränkungen fragen. Wenn eine Story zu vage oder unzureichend definiert ist, um sinnvoll diskutiert zu werden, sollte sie zur weiteren Ausarbeitung an den Product Owner zurückgegeben werden – statt sie unter Unsicherheit zu schätzen.

Schritt 2: Anonym und unabhängig schätzen

Sobald das Team das Gefühl hat, die Story ausreichend zu verstehen, wählt jedes Teammitglied privat eine Karte aus seinem Deck, die seine Einschätzung der relativen Komplexität der Story widerspiegelt. Die Kartenwerte folgen typischerweise der Fibonacci-Folge: 1, 2, 3, 5, 8, 13, 21, und manchmal höhere Werte oder Sonderkarten wie ∞ (zu groß zum Schätzen) oder ? (nicht genug Informationen).

Die entscheidende Anforderung in dieser Phase ist, dass die Schätzungen unabhängig voneinander gebildet werden, ohne Beeinflussung durch andere Teammitglieder. Niemand teilt seine Zahl mit, niemand deutet seine Karte an, und die Körpersprache bleibt neutral. Diese Unabhängigkeit ist es, die Planning Poker wirksam macht – sie bewahrt die Vielfalt der Perspektiven, die ein rein diskussionsbasierter Ansatz auflösen würde.

Schritt 3: Gleichzeitig aufdecken

Wenn alle ihre Wahl getroffen haben, fordert der Moderator zum Aufdecken auf. Alle Teammitglieder zeigen ihre Karten im selben Moment. Dieses gleichzeitige Aufdecken ist der Mechanismus, der Anchoring verhindert – den gut dokumentierten kognitiven Bias, bei dem Menschen ihre Einschätzung an die erste gehörte Zahl anpassen.

Wenn alle Schätzungen identisch oder sehr ähnlich sind, ist schnell Konsens hergestellt, und das Team notiert die Schätzung und geht zur nächsten Story über. Wenn die Schätzungen erheblich voneinander abweichen, geht die Session zum wichtigsten Schritt über.

Schritt 4: Diskutieren, bis Konsens gefunden ist

Wenn die Schätzungen divergieren, diskutiert das Team. Die Teilnehmenden mit den höchsten und niedrigsten Schätzungen werden typischerweise gebeten, zuerst ihre Begründung zu erklären. Diese strukturierte Diskussion bringt unterschiedliche Annahmen, versteckte Risiken und Wissenslücken ans Licht, die in einer einfachen Gruppendiskussion möglicherweise nicht aufgetaucht wären.

Nach der Diskussion stimmt das Team erneut ab. Dieser Prozess wiederholt sich, bis das Team eine gemeinsame Schätzung findet – oder bis es entscheidet, die Story in kleinere, besser handhabbare Teile aufzuteilen und diese separat zu schätzen. Das Ziel ist nicht, durch Kompromiss Einigkeit zu erzwingen, sondern ein gemeinsames Verständnis der Arbeit zu erreichen.

Wer sollte teilnehmen?

Das Entwicklungsteam bildet den Kern einer Planning-Poker-Session. Diese Personen werden das Produkt tatsächlich bauen, und ihre Schätzungen sollten ihr gemeinsames Verständnis der technischen Komplexität widerspiegeln. Alle relevanten Disziplinen einzubeziehen – Entwickler, QA, UX und alle anderen, die zur Story beitragen – liefert genauere und vollständigere Schätzungen.

Der Product Owner ist anwesend, stimmt aber typischerweise nicht ab. Seine Rolle ist es, zu definieren, was benötigt wird, Fragen zu beantworten und Akzeptanzkriterien zu klären. Die Anwesenheit des Product Owners in Echtzeit reduziert die Anzahl unklarer Stories, die zur späteren Verfeinerung zurückgestellt werden müssen, erheblich.

Der Scrum Master moderiert die Session – behält die Zeit im Blick, verwaltet den Prozess und stellt sicher, dass die Regeln (insbesondere das gleichzeitige Aufdecken) eingehalten werden. Ein effektiver Scrum Master schafft Raum für ruhigere Teammitglieder, ihre Schätzungen zu teilen, und verhindert, dass dominante Stimmen die Gruppe vor dem Aufdecken der Karten beeinflussen.

Warum Planning Poker funktioniert

Planning Poker ist effektiv, weil es die Weisheit der Gruppe mit strukturierten Prozesskontrollmechanismen verbindet. Durch die Anforderung unabhängiger privater Schätzungen vor jeder Gruppendiskussion erfasst es eine breitere Palette von Perspektiven als ein einfaches Handaufheben oder ein Top-down-Ansatz. Durch die Anforderung einer Diskussion bei divergierenden Schätzungen stellt es sicher, dass Meinungsverschiedenheiten angesprochen und nicht übergangen werden.

Das Ergebnis sind Schätzungen, die das gesamte Team versteht und trägt – was letztlich wertvoller ist als die Prognose eines einzelnen Experten.