Ratgeber · 10 Min. Lesezeit

Planning Poker durchführen (Schritt für Schritt)

Erfahre Schritt für Schritt, wie Planning Poker abläuft: Raum einrichten, Kartensatz wählen, Stimmen gleichzeitig aufdecken, Abweichungen besprechen und zu einer verlässlichen Schätzung kommen.

Planning Poker ist eine konsensbasierte Schätzmethode: Jedes Teammitglied wählt verdeckt eine Karte für den Aufwand einer Aufgabe, alle decken gleichzeitig auf und das Team diskutiert Abweichungen, bis es sich auf eine gemeinsame Schätzung einigt. Es ist die am weitesten verbreitete Methode des Expertenurteils in der Forschung zu agiler Schätzung. Für den Ablauf braucht ihr ein Team, eine Liste zu schätzender Aufgaben und einen Kartensatz. Dann folgen die sieben Schritte unten.

Was ist Planning Poker?

Planning Poker (auch Scrum Poker oder Pointing Poker genannt) macht aus einer Schätzung ein kurzes, strukturiertes Spiel. Statt dass die lauteste oder ranghöchste Person eine Zahl vorgibt, legt sich jeder verdeckt auf eine Einschätzung fest und alle decken gleichzeitig auf. Genau diese Regel sorgt dafür, dass die Methode funktioniert.

Warum es funktioniert: die Wissenschaft des gemeinsamen Schätzens

Der Grund für das gleichzeitige Aufdecken ist, Ankereffekte zu vermeiden: Dabei zieht die zuerst genannte Zahl die Schätzungen aller anderen in ihre Richtung. In kontrollierten Experimenten beeinflusste eine beliebige Zahl, die Softwarefachleuten vor ihrer Schätzung gezeigt wurde, deren Ergebnisse stark. Der Effekt war ausgeprägt. Ein Trainingsworkshop, der ihn abschwächen sollte, verringerte den Einfluss, beseitigte ihn aber nicht. Ankereffekte gelten seit Langem als wichtige Ursache für zu optimistische Aufwandsschätzungen in der Softwareentwicklung.

Auch gemeinsames Schätzen hilft. In einer Studie mit echten Projektaufgaben war die gemeinsam nach einer Diskussion vereinbarte Schätzung weniger optimistisch als der einfache Durchschnitt individueller Vermutungen und lag näher am tatsächlichen Aufwand. (Vollständige Nachweise stehen unter „Quellen“.)

Was du vor dem Start brauchst

  • Ein Team aus den Personen, die die Arbeit erledigen werden (üblicherweise 3 bis 9).
  • Eine priorisierte Liste von User Stories oder Aufgaben.
  • Einen Schätzungskartensatz (siehe Schritt 2).
  • Eine moderierende Person (oft der Scrum Master) sowie jemanden, der Fragen zu den Aufgaben beantworten kann (oft die Product Ownerin oder der Product Owner).

Planning Poker durchführen: 7 Schritte

  1. Raum einrichten und Team einladen. Erstellt eine Sitzung und teilt den Link. Bei Planning Poker Web, einem kostenlosen Planning-Poker-Tool, kann jede Person ohne Konto beitreten: Link öffnen, fertig. Moderationstipp: Einigt euch vorher auf einen Kartensatz und eine Referenz-Story („Dieser kleine Fehler entspricht 2 Punkten“), damit alle dieselbe Skala verwenden.
  2. Schätzungskartensatz auswählen. Wählt die Skala, mit der das Team abstimmt (Fibonacci, T-Shirt-Größen usw.). Tipp: Verwendet in allen Sprints denselben Kartensatz, damit eure Velocity vergleichbar bleibt.
  3. Erste User Story vorstellen. Die Product Ownerin oder der Product Owner liest den Eintrag vor und beantwortet Verständnisfragen. Haltet die Vorstellung kurz, denn Details ergeben sich aus der Diskussion. Als Richtwert: etwa zwei Minuten.
  4. Alle stimmen gleichzeitig ab. Jede Person wählt verdeckt die Karte, die ihrem Gefühl für den Aufwand entspricht. Es werden noch keine Zahlen ausgesprochen. Tipp: Bezieht alle ein, die an der Arbeit beteiligt sind – auch Testende und Designende, nicht nur Entwickelnde.
  5. Alle Karten gleichzeitig aufdecken. Sobald alle abgestimmt haben, deckt ihr gleichzeitig auf. Dieser Schritt verhindert Ankereffekte: Niemand wurde von der Stimme einer anderen Person beeinflusst.
  6. Abweichungen besprechen. Wenn die Schätzungen auseinandergehen, erläutern die Personen mit der höchsten und niedrigsten Stimme ihre Überlegungen. Dadurch werden verborgene Annahmen, fehlende Aufgaben und Risiken sichtbar – oft der wertvollste Teil der Sitzung. Plant etwa drei bis fünf Minuten dafür ein. Dauert es länger, ist die Story wahrscheinlich zu groß.
  7. Erneut abstimmen, bis ihr euch einigt. Stimmt nach der Diskussion erneut ab. Wiederholt den Vorgang, bis ihr eine gemeinsame Zahl gefunden habt. Haltet sie fest und geht zur nächsten Aufgabe über. Tipp: „Einigen“ bedeutet, nah genug beieinander zu liegen, nicht dieselbe Karte zu wählen. Strebt keine Einstimmigkeit um jeden Preis an.

Beispiel: eine User Story schätzen

Nehmen wir die Story „Nutzende können ihr Passwort per E-Mail zurücksetzen“. Die Product Ownerin liest sie vor; eine Testperson fragt, ob die Begrenzung der Anfragen zum Umfang gehört (ja). Das Team stimmt mit einem Fibonacci-Kartensatz ab:

PersonEntwicklerin AEntwickler BTestpersonDesignperson
Stimme3382

Die Testperson (8) erläutert: Der Ablauf für das Zurücksetzen braucht eine Begrenzung der Anfragen, Arbeit an der E-Mail-Vorlage und Sonderfälle für abgelaufene Tokens – daran hatte sonst niemand gedacht. Genau solche verborgene Arbeit soll Planning Poker sichtbar machen. Nach der Diskussion stimmt das Team erneut ab (5, 5, 8, 5) und einigt sich auf 5. Wichtiger als die Zahl ist, dass nun das ganze Team dasselbe Bild vom Arbeitsumfang hat.

Planning Poker aus der Ferne oder vor Ort

Der Ablauf ist gleich, die Moderation unterscheidet sich.

  • Vor Ort: Physische Karten funktionieren, aber jemand muss die Ergebnisse übertragen; außerdem gibt es keinen automatischen Verlauf. Achtet darauf, dass langsames Aufdecken andere nicht beeinflusst.
  • Remote oder verteilt: Ein gemeinsamer Online-Raum ist unverzichtbar. Das Tool setzt das gleichzeitige Aufdecken durch, erfasst Ergebnisse und Verlauf automatisch, und asynchrone Stimmen ermöglichen Schätzungen über Zeitzonen hinweg ohne Live-Termin. Hier ersetzt ein Tool wie Planning Poker Web den physischen Kartensatz vollständig. Tipps für Live- und asynchrone Abläufe findest du in unserem Beitrag zu Planning Poker für Remote-Teams.

Wann du Planning Poker NICHT einsetzen solltest

Planning Poker passt nicht immer. Lass es aus oder wähle eine schnellere Methode, wenn:

  • Das Backlog riesig ist (mehr als 50 Aufgaben). Die Abstimmung jeder einzelnen Aufgabe dauert zu lange. Nutzt Affinitätsschätzung oder das Bucket-System als erste Runde und schätzt anschließend nur die unsicheren Aufgaben mit Planning Poker.
  • Eine Person die Arbeit eindeutig allein erledigt. Ohne unterschiedliche Perspektiven bringt das Gruppenritual kaum mehr als eine kurze Expertenschätzung.
  • Das Team bereits dasselbe klare Verständnis hat. Bei vertrauter, wiederkehrender Arbeit weichen die Schätzungen selten ab; die Diskussion bringt dann wenig Neues ans Licht.
  • Ihr für eine langfristige Roadmap statt für einen Sprint schätzt. Grobe Größen (T-Shirt-Größen) genügen; präzise relative Punkte sind für einen so weit entfernten Zeitraum verschwendete Arbeit.

Ehrlichkeit darüber schafft Vertrauen. Planning Poker in unpassenden Situationen zu erzwingen, führt dazu, dass Teams Schätzungen irgendwann ablehnen.

Schwierige Situationen (und wie du damit umgehst)

  • Nach zwei Runden gibt es noch keine Einigung. Die Story ist meist zu groß oder zu unklar. Teilt sie auf oder bittet die Product Ownerin bzw. den Product Owner um Klärung.
  • Eine Person dominiert die Diskussion. Die verdeckte Abstimmung begrenzt diesen Einfluss bereits. Verstärkt den Effekt, indem ihr zuerst die Person mit der niedrigsten Stimme sprechen lasst, nicht die ranghöchste.
  • Jemand stimmt immer mit der Mehrheit. Bittet diese Person, abzustimmen, bevor sie die Stimmen der anderen kennt. In einem Tool bleiben die Stimmen bis zum Aufdecken verborgen; das nimmt die Versuchung.
  • Schätzungen sind durchweg zu niedrig. Das sind Optimismus und Ankereffekte. Verwendet eine sichtbare Referenz-Story und vergleicht neue Aufgaben mit ihr, statt ohne Bezugspunkt zu schätzen.

Planning Poker und andere Schätzmethoden

MethodeAblaufTempoVerhindert Ankereffekte?Besonders geeignet für
Planning PokerVerdeckte Stimme, gleichzeitiges Aufdecken, DiskussionMittelJa (gleichzeitiges Aufdecken)Teams, die Diskussion und Konsens möchten
T-Shirt-GrößenEinordnung in S/M/L/XLSchnellTeilweiseErste grobe Einschätzung
Bucket-SystemAufgaben in Größen-„Eimer“ einordnenSehr schnellTeilweiseGroße Backlogs mit vielen Aufgaben
AffinitätsschätzungAufgaben nach Ähnlichkeit gruppierenSehr schnellTeilweiseErste Runde über viele Aufgaben
Wideband DelphiAnonyme Runden mit ModerationLangsamJaSchätzungen mit hohem Risiko

Häufige Fehler vermeiden

  • Eine Zahl vor dem Aufdecken nennen: Dadurch entstehen wieder Ankereffekte.
  • In Stunden statt relativen Punkten schätzen: Relative Größen sind schneller und weniger verzerrt.
  • Den Durchschnitt bilden statt zu diskutieren: Die Diskussion ist das Ziel; die Zahl ist ein Nebenprodukt.
  • Eine Person dominieren lassen: Die verdeckte Abstimmung dient gerade dazu, das zu verhindern.
  • Endlos neu abstimmen: Einstimmigkeit zu erzwingen kostet Zeit. Ziel ist „nah genug, um sich zu einigen“.

Glossar der Planning-Poker-Begriffe

  • Story Point: Einheit des relativen Aufwands (keine Stunden), die Komplexität, Unsicherheit und Arbeitsumfang verbindet.
  • Kartensatz: Die Kartenauswahl, mit der das Team abstimmt (zum Beispiel Fibonacci oder T-Shirt-Größen).
  • Velocity: Anzahl der Punkte, die ein Team pro Sprint abschließt; sie dient der Prognose, nicht dem Teamvergleich.
  • Ankereffekt: Verzerrung, bei der die zuerst genannte Zahl andere Schätzungen beeinflusst. Deshalb werden Stimmen gleichzeitig aufgedeckt.
  • Abweichende Stimme: Die höchste oder niedrigste Schätzung, deren Begründung das Team zuerst bespricht.
  • Referenz-Story: Eine zuvor geschätzte Aufgabe, mit der neue Stories verglichen werden, damit die Skala stabil bleibt.

Häufig gestellte Fragen

Wie lange dauert eine Planning-Poker-Sitzung?

Für ein übliches Sprint-Backlog etwa 30 bis 60 Minuten. Eine einzelne Aufgabe dauert meist ein bis drei Minuten, es sei denn, abweichende Schätzungen erfordern eine Diskussion.

Wie viele Personen sollten mitmachen?

Üblicherweise drei bis neun Personen, die die Arbeit tatsächlich erledigen. Bei weniger als drei fehlen unterschiedliche Perspektiven; bei mehr als neun verlangsamt sich die Diskussion.

Welchen Kartensatz sollten wir verwenden?

Fibonacci (0, 1, 2, 3, 5, 8, 13 und höher) ist die übliche Voreinstellung, denn die wachsenden Abstände spiegeln zunehmende Unsicherheit bei größeren Aufgaben wider. Für frühe, grobe Einschätzungen eignen sich T-Shirt-Größen.

Warum werden alle Karten gleichzeitig aufgedeckt?

Damit kein Ankereffekt entsteht – also die zuerst genannte Zahl die Schätzungen aller anderen beeinflusst. Gleichzeitiges Aufdecken hält jede Stimme unabhängig.

Schätzen wir in Stunden oder Punkten?

Relative Punkte (Story Points) sind empfehlenswert. Sie lassen sich schneller vereinbaren und sind weniger anfällig für den in der Forschung beobachteten Optimismus bei Stundenschätzungen.

Was tun, wenn sich das Team nicht einigen kann?

Lasst die Personen mit der höchsten und niedrigsten Stimme ihre Gründe erläutern und stimmt erneut ab. Wenn keine Einigung zustande kommt, ist die Aufgabe wahrscheinlich zu groß oder unklar. Teilt sie auf oder bittet um Klärung.

Kann Planning Poker asynchron durchgeführt werden?

Ja. Mit einem Online-Tool stimmen Teammitglieder zu ihrer eigenen Zeit ab und decken auf, sobald alle abgestimmt haben. Das hilft verteilten Teams in unterschiedlichen Zeitzonen. Der Schutz vor Ankereffekten bleibt erhalten, weil die Stimmen bis zum Aufdecken verborgen sind.

Wer sollte teilnehmen, und sollte der Scrum Master abstimmen?

Alle Personen, die die Arbeit erledigen (Entwickelnde, Testende, Designende). Der Scrum Master moderiert üblicherweise, statt abzustimmen. Die Product Ownerin oder der Product Owner beantwortet Fragen, schätzt aber nicht mit.

Ist Planning Poker dasselbe wie Scrum Poker?

Ja. „Scrum Poker“ und „Pointing Poker“ sind verbreitete Synonyme für dieselbe Methode.

Quellen

  1. Moløkken-Østvold, Haugen & Benestad (2008). Using planning poker for combining expert estimates in software projects. Journal of Systems and Software, 81(12), 2106–2117.
  2. Mahnič & Hovelja (2012). On using planning poker for estimating user stories. Journal of Systems and Software, 85(9), 2086–2095.
  3. Jørgensen & Sjøberg (2001). Anchoring effects: an important cause of too optimistic effort estimates. Simula.
  4. Løhre & Jørgensen (2016). Numerical anchors and their strong effects on software development effort estimates. Journal of Systems and Software.
  5. Shepperd et al. (2018). An Experimental Evaluation of a De-biasing Intervention for Professional Software Developers. arXiv:1804.03919.

Weiterlesen