Planning Poker: Wie Agile-Teams den Aufwand schätzen

Planning Poker ist die Schätztechnik, die aus einer potenziell konfliktreichen Backlog-Grooming-Sitzung eine strukturierte, überraschend unterhaltsame Teamübung macht. Es klingt einfach, aber die Mechanik ist geschickt darauf ausgelegt, genau die Meinungsverschiedenheiten sichtbar zu machen, auf die es ankommt.

Was ist Planning Poker?

Planning Poker (auch Scrum Poker genannt) ist eine konsensbasierte, spielerische Schätztechnik, die Agile-Teams nutzen, um User Stories und Backlog-Einträge zu bemessen. Jeder Teilnehmer hält einen Satz nummerierter Karten. Jeder wählt privat eine Karte, dann werden alle Karten gleichzeitig aufgedeckt. Weichen die Schätzungen deutlich voneinander ab, bespricht das Team die Lücke, bevor erneut abgestimmt wird, bis Konsens erreicht ist.

Die Methode wurde 2002 von James Grenning eingeführt und später von Mike Cohn in seinem Buch Agile Estimating and Planning (2005) populär gemacht. Cohns Darstellung, zusammen mit der breiten Verbreitung von Scrum, machte Planning Poker zum De-facto-Schätzwerkzeug in Teams weltweit, die nach der Agile-Methodik arbeiten.

Die zentrale Erkenntnis hinter Planning Poker ist, dass Schätzung am besten als Gespräch funktioniert, nicht als Berechnung. Wenn alle gleichzeitig eine Zahl auf den Tisch legen, erhält man ungefiltertes individuelles Urteilsvermögen. Die anschließenden Meinungsverschiedenheiten sind keine Reibung, sondern das eigentliche Signal.

Key Facts

• Teams, die strukturierte Schätztechniken wie Planning Poker einsetzen, berichten von 29 % höherem Vertrauen in ihre Sprint-Verpflichtungen im Vergleich zu unstrukturierter Größenbestimmung (State of Agile Report, 17. Ausgabe, 2024).
• 81 % der Agile-Praktiker nutzen Story Points als primäre Schätzeinheit, wobei Planning Poker die gängigste Methode zu deren Zuweisung ist (State of Agile Report, 17. Ausgabe, 2024).
• Mike Cohn, der Planning Poker populär gemacht hat, stellt fest, dass der primäre Wert der Technik "in der Diskussion liegt, die sie auslöst, nicht in der Zahl, die sie hervorbringt" (Mountain Goat Software, agileestimating.com).

Warum Planning Poker funktioniert

Die Wirksamkeit von Planning Poker ist kein Zufall. Das Design adressiert drei konkrete Schwachstellen, die traditionelle Top-down-Schätzungen plagen.

Es reduziert Verankerungseffekte. Wenn ein erfahrener Entwickler sagt "das sieht nach einer Zweitages-Aufgabe aus", bevor jemand anderes gesprochen hat, zieht das unabhängig von individuellem Fachwissen das gesamte Team zu dieser Zahl hin. Das gleichzeitige Aufdecken der Karten bricht diese Dynamik vollständig auf. Jeder legt sich auf seine Schätzung fest, bevor er die Schätzung anderer sieht, wodurch die Gruppe echte unabhängige Datenpunkte erhält.

Es macht versteckte Annahmen sichtbar. Der interessante Moment in jeder Planning-Poker-Runde ist nicht, wenn alle übereinstimmen, sondern wenn die Schätzungen über mehrere Werte streuen. Ein Entwickler, der 3 wählt, während ein anderer 13 wählt, hat mit hoher Wahrscheinlichkeit ein anderes mentales Modell davon, was die Story erfordert. Diese Meinungsverschiedenheit offenbart eine fehlende Anforderung, ein unklares Akzeptanzkriterium oder eine Abhängigkeit, an die niemand gedacht hat. Solche Lücken sollten Sie im Schätzmeeting finden, nicht mitten im Sprint.

Es bindet das gesamte Team ein. Bei vielen Schätzansätzen schätzt ein Tech Lead und alle anderen nicken zustimmend. Planning Poker gibt jeder Stimme gleiches Gewicht. Die Junior-Entwicklerin, die eine hohe Karte wählt, weil sie sich an eine ähnliche Story erinnert, die sich als deutlich schwieriger als erwartet herausstellte, kann ihre Überlegung erklären. Dieses institutionelle Wissen kommt sonst oft nicht zum Vorschein.

Planning Poker schafft auch psychologisches Mitverantwortungsgefühl. Wenn ein Team gemeinsam schätzt, ist es eher bereit, sich gegenseitig für die gemeinsame Verpflichtung zur Rechenschaft zu ziehen, weil es sie gemeinsam eingegangen ist.

Häufige Fehler und Grenzen

Planning Poker ist wirkungsvoll, aber es lässt sich auch schlecht durchführen.

Über Meinungsverschiedenheiten hinweggehen. Wenn zwei Personen weit auseinanderliegen, ist die Versuchung groß, die Differenz zu teilen und weiterzumachen. Tun Sie das nicht. Die Lücke sagt Ihnen etwas. Nehmen Sie sich drei bis fünf Minuten, um jede Perspektive zu verstehen, bevor erneut abgestimmt wird.

Erfahrene Stimmen dominieren lassen. Selbst bei gleichzeitigem Aufdecken kann ein Tech Lead, der seine niedrige Kartenschätzung sofort erklärt, bevor andere gesprochen haben, die Diskussion immer noch verankern. Moderatoren sollten den Inhaber der höchsten Karte bitten, zuerst zu sprechen.

Es für alles einsetzen. Planning Poker ist für User Stories auf der richtigen Granularitätsebene konzipiert. Es zur Bemessung von Epics oder mehrere Quartale umfassenden Initiativen zu verwenden, erzeugt Zahlen ohne Aussagekraft. Zu große Elemente sollten vor der Schätzung aufgeteilt werden.

Die Schätzung als Versprechen behandeln. Die entstehende Zahl ist eine relative Größenschätzung, keine Frist. Teams, die Story Points mit Stunden verwechseln, erzeugen Druck, der künftige Schätzungen verfälscht.

Es ohne bereite Stories durchführen. Fehlen klare Akzeptanzkriterien, wird Planning Poker zu einer Debatte über Interpretation statt über Aufwand. Elemente sollten eine Definition of Ready erfüllen, bevor sie in die Schätzung gehen.

So spielen Sie Planning Poker (Schritt für Schritt)

Schritt 1: Das Kartendeck vorbereiten

Jeder Teilnehmer erhält einen Satz Schätzkarten. Das Standarddeck verwendet eine modifizierte Fibonacci-Folge: 0, 1, 2, 3, 5, 8, 13, 20, 34, 55, 89 sowie Sonderkarten für "?" (zu unsicher zum Schätzen) und eine Kaffeetasse (Pause nötig). Der nichtlineare Abstand spiegelt die Tatsache wider, dass größere Arbeit proportional mehr Unsicherheit birgt. Die meisten Teams fügen am unteren Ende zusätzlich 0,5 und 1 für sehr kleine Elemente hinzu.

Physische Kartendecks funktionieren gut. Online-Tools wie Pointing Poker, PlanITpoker sowie integrierte Funktionen in Jira und Azure DevOps unterstützen verteilte Teams.

Schritt 2: Die Story laut vorlesen

Der Product Owner (oder wer auch immer das Backlog verantwortet) liest der Gruppe die User Story und die Akzeptanzkriterien vor. Teilnehmer stellen klärende Fragen. Dies ist nicht der Zeitpunkt für die Schätzung, sondern dafür, sicherzustellen, dass alle dieselbe Story verstehen. Ein Klärungsfenster von zwei bis drei Minuten ist üblich.

Schritt 3: Privat schätzen

Jeder Teilnehmer wählt aus seinem Kartensatz die Karte, die seine Größenschätzung für die Story darstellt. Die Karten bleiben verdeckt. Niemand kündigt seine Zahl an oder reagiert während dieser Phase auf jemand anderen. Ziel ist echtes, unabhängiges Urteilsvermögen.

Schritt 4: Gleichzeitig aufdecken

Auf ein Zeichen (oder einen Klick in einem Online-Tool) dreht jeder gleichzeitig seine Karte um. Das verhindert, dass die zuletzt aufdeckende Person von dem beeinflusst wird, was andere bereits gezeigt haben.

Schritt 5: Die Ausreißer besprechen

Zeigen alle Karten dieselbe Zahl (oder benachbarte Zahlen), notiert das Team die Konsensschätzung und macht weiter. Bei deutlicher Streuung bittet der Moderator die Inhaber der höchsten und niedrigsten Karte, ihre Überlegung zu erklären. Hier entsteht der eigentliche Mehrwert. Lassen Sie die Diskussion drei bis fünf Minuten laufen und stimmen Sie dann erneut ab.

Schritt 6: Bis zum Konsens erneut abstimmen

Nach der Diskussion schätzt jeder erneut. Wiederholen Sie die Schritte 3 bis 5, bis sich die Gruppe annähert. In den meisten Fällen erfolgt die Annäherung in ein oder zwei Runden. Braucht eine Story mehr als drei Runden ohne Annäherung, sollte sie möglicherweise aufgeteilt oder für weitere Recherche zurückgestellt werden.

Beispiel für Planning Poker

Hier ist eine typische Runde für eine Story: "Als Nutzer möchte ich mein Passwort per E-Mail zurücksetzen können, damit ich wieder Zugriff auf mein Konto erhalte."

Diskussion: Entwickler B weist darauf hin, dass das Team beim letzten E-Mail-basierten Feature unerwartete Zustellbarkeitsprobleme im Staging-Bereich hatte, die zwei Tage kosteten. Entwickler A gibt zu, diesen Testaufwand nicht berücksichtigt zu haben. Das Team einigt sich darauf, dass die Story vor der erneuten Abstimmung ein Akzeptanzkriterium benötigt, das das Verhalten bei abgelaufenen Tokens ausdrücklich abdeckt.

Erneute Abstimmung: Entwickler A: 8, Entwickler B: 8, QA: 8. Konsens bei 8 Story Points.

Die endgültige Schätzung liegt 60 % höher als die erste Abstimmung von Entwickler A. Diese Lücke war kein Fehler, sondern das System hat funktioniert.

Planning-Poker-Tools und Kartendecks

Physische Karten eignen sich gut für Teams am selben Standort. Gedruckte Decks sind kostengünstig und verleihen dem Meeting ein haptisches Ritual. Eine kurze Suche nach "Planning Poker Karten" liefert viele Optionen, einschließlich kostenloser druckbarer Vorlagen.

Online-Tools sind der Standard für verteilte Teams:

• Pointing Poker (pointingpoker.com): einfach, kostenlos, keine Anmeldung nötig
• PlanITpoker (planitpoker.com): enthält Verlauf und Sitzungsverwaltung
• Jira: natives Planning Poker über das Sprint-Planning-Board (erfordert eine App eines Drittanbieters)
• Azure DevOps: Integration über Erweiterungen wie Estimate

Die von Teams am häufigsten verwendeten Kartenwerte:

Die meisten Teams bleiben bei der modifizierten Fibonacci-Folge. Die Abstände zwischen großen Zahlen (13 gegenüber 20 gegenüber 40) spiegeln echte Unsicherheit bei größerem Umfang wider, was die ehrliche Herangehensweise ist.

Best Practices

Bereiten Sie Ihr Backlog vor der Sitzung vor. Stories ohne Akzeptanzkriterien verschwenden die Zeit des gesamten Teams. Führen Sie einen kurzen Vor-Grooming-Durchgang durch, damit Elemente vor der Schätzung eine Definition of Ready erfüllen.

Timeboxen Sie jede Story. Eine Diskussionsgrenze von zwei bis drei Minuten pro Story hält die Sitzung in Bewegung. Verbraucht eine Story weiterhin Zeit, teilen Sie sie auf.

Wechseln Sie den Moderator ab. Wenn immer dieselbe Person jede Sitzung leitet, entsteht eine Machtdynamik, die abweichende Schätzungen subtil unterdrücken kann. Ein Wechsel hält alle gleichermaßen engagiert.

Verankern Sie nicht vor dem Aufdecken. Vermeiden Sie Aussagen wie "das wirkt klein" oder "ich habe drei Tage an etwas Ähnlichem gearbeitet", bevor die Karten gezeigt werden. Diese färben die Schätzung ein, bevor das Aufdecken die Chance hat, unabhängige Daten zu liefern.

Verwenden Sie Story Points nicht als Stunden. Der ganze Sinn der relativen Größenbestimmung besteht darin, Aufwand von Kalenderzeit zu entkoppeln. Sobald Story Points zu einem Stellvertreter für Stunden werden, verlieren Sie das Geschwindigkeitssignal, das sie erzeugen sollen.

Überspringen Sie nicht die Erklärung der höchsten Karte. Die Person mit der höchsten Karte hat meist Informationen, die der Rest des Teams nicht hat. Ihre Erklärung sind oft die wertvollsten drei Minuten der Sitzung.

Häufig gestellte Fragen

Warum werden alle Karten gleichzeitig aufgedeckt?

Das gleichzeitige Aufdecken verhindert Verankerung. Würden Schätzungen nacheinander bekannt gegeben, würde jede Person von den bereits sichtbaren Zahlen beeinflusst. Der ganze Sinn besteht darin, unabhängige Urteile zu sammeln und sie dann zu vergleichen, nicht darin, durch sequenziellen sozialen Druck zu einer Einigung zu gelangen.

Wie lange sollte Planning Poker dauern?

Für eine zweiwöchige Sprint-Planung schätzen die meisten Teams 15 bis 30 Backlog-Einträge und planen 60 bis 90 Minuten für den Schätzteil ein. Stories, deren Schätzung länger als fünf Minuten dauert, sind meist ein Signal, dass sie aufgeteilt oder besser definiert werden müssen.

Wie schneidet Planning Poker im Vergleich zur T-Shirt-Größenbestimmung ab?

Beides sind relative Schätzmethoden. Die T-Shirt-Größenbestimmung (XS, S, M, L, XL) ist schneller und eignet sich gut für die frühe Roadmap-Planung oder wenn nicht-technische Stakeholder beteiligt sind. Planning Poker liefert granularere Ergebnisse (tatsächliche Zahlen auf einer Skala) und erzwingt eine expliziteren Diskussion, wodurch es besser für die Sprint-Planung geeignet ist, wo das Team Verpflichtungen benötigt, die es mit einem Burndown-Chart verfolgen kann.

Was, wenn das Team nie einen Konsens erreicht?

Konvergieren mehrere Runden nicht, braucht die Story wahrscheinlich mehr Arbeit. Häufige Ursachen: Der Umfang ist unklar, die Story umfasst mehrere unabhängige Aspekte, oder es gibt eine Abhängigkeit, die noch niemand vollständig versteht. Der richtige Schritt ist, das Element zurückzustellen, einen Verantwortlichen für die Klärung zu benennen und in der nächsten Sitzung erneut zu schätzen.

Kann Planning Poker auch für Nicht-Software-Teams funktionieren?

Ja. Jedes Team, das relativen Aufwand schätzt, Marketingkampagnen, Content-Produktion, Betriebsprojekte, kann die Technik nutzen. Die Kartenwerte und das Story-Format übertragen sich direkt. Was sich nicht überträgt, ist die Verwendung softwarespezifischer Story Points; Nicht-Software-Teams ersetzen sie oft durch Aufwandsstufen (Niedrig, Mittel, Hoch, Sehr hoch), die für den gleichen Effekt Zahlen zugeordnet werden.

---

Die Beständigkeit von Planning Poker in der Agile-Methodik lässt sich auf einen Punkt zurückführen: Es macht Schätzung zu einem Teamgespräch statt zu einer individuellen Vorhersage. Die Zahl, die am Ende dabei herauskommt, ist nützlich, um Verpflichtungen aus der Sprint-Planung und die Geschwindigkeit im Burndown-Chart zu verfolgen. Aber der eigentliche Ertrag ist das gemeinsame Verständnis dessen, was eine Story tatsächlich beinhaltet, und genau dieses Verständnis lässt den Sprint funktionieren.

Related reading

• Was ist Scrum?
• Sprint-Planung: Wie man ein effektives Meeting durchführt
• Sprint-Retrospektive
• User Stories
• Burndown-Chart
• Agile-Manifest