Planning Poker: Agiles Schätzen mit Fibonacci-Karten

Planning Poker ist eine spielerische Schätzmethode in agilen Teams, bei der alle Mitglieder verdeckt eine Fibonacci-Karte wählen und gleichzeitig aufdecken. So entstehen im Konsens relative Aufwandsschätzungen für Story Points, ohne dass einzelne Meinungen die Gruppe verzerren.

Kategorie:Agile Methoden

Planning Poker (auch Scrum Poker genannt) ist eine konsensbasierte Schätztechnik, mit der agile Teams den Aufwand von User Stories und Backlog-Items gemeinsam bewerten. Statt eine absolute Dauer in Stunden oder Tagen zu nennen, vergeben die Teammitglieder relative Werte - meist in Story Points auf Basis der Fibonacci-Folge. Der spielerische Kartenmechanismus sorgt dafür, dass jede Stimme zunächst unbeeinflusst bleibt und Abweichungen bewusst diskutiert werden.

Ursprung und Idee

Die Methode wurde Anfang der 2000er Jahre im agilen Umfeld populär und verbindet zwei Grundgedanken: relative Schätzung und kollektive Intelligenz. Relative Schätzung bedeutet, dass Aufgaben im Vergleich zueinander bewertet werden ("diese Story ist etwa doppelt so aufwändig wie jene"), nicht in absoluten Zeiteinheiten. Kollektive Intelligenz nutzt das verteilte Wissen des gesamten Teams - Entwicklung, Test und fachliche Perspektive fließen gemeinsam in die Schätzung ein.

Die Fibonacci-Folge als Kartenwerte

Die Karten tragen typischerweise Werte der Fibonacci-Folge: 1, 2, 3, 5, 8, 13, 21. Der wachsende Abstand zwischen den Zahlen ist bewusst gewählt: Je größer und unsicherer eine Aufgabe, desto ungenauer wird jede Schätzung. Die Sprünge zwingen das Team, sich für eine Größenordnung zu entscheiden, statt über Scheingenauigkeiten wie "6 oder 7" zu streiten.

  • Fibonacci (1, 2, 3, 5, 8, 13, 21): Der Klassiker, bildet zunehmende Unsicherheit natürlich ab.
  • Modifizierte Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100): Runde große Werte für bessere Lesbarkeit.
  • Sonderkarten: Häufig ergänzt durch die "0" (bereits erledigt), "?" (zu wenig Information für eine Schätzung), "unendlich" (viel zu groß, muss aufgeteilt werden) und eine Kaffeetassen-Karte für eine Pause.

Ablauf einer Schätzrunde

Eine typische Planning-Poker-Runde folgt einem klaren Muster:

  1. Vorstellung: Der Product Owner stellt eine User Story vor und erläutert Ziel und Akzeptanzkriterien.
  2. Klärung: Das Team stellt Rückfragen, um offene Punkte und Abhängigkeiten zu verstehen.
  3. Verdeckte Wahl: Jedes Mitglied wählt unabhängig eine Karte, die seine Einschätzung repräsentiert - noch verdeckt, damit niemand beeinflusst wird.
  4. Gleichzeitiges Aufdecken: Auf ein Signal decken alle ihre Karten gleichzeitig auf.
  5. Diskussion bei Abweichung: Weichen die Werte stark ab, erläutern besonders die höchste und die niedrigste Schätzung ihre Gründe. Oft kennt jemand ein Risiko oder einen einfacheren Weg, den andere nicht gesehen haben.
  6. Erneute Runde: Nach der Diskussion wird erneut geschätzt, bis sich die Werte annähern oder ein Konsens erreicht ist.

Warum verdeckte und gleichzeitige Aufdeckung?

Der Kern der Methode liegt im gleichzeitigen Aufdecken. Würden die Schätzungen nacheinander genannt, entstünde ein Anker-Effekt: Die erste genannte Zahl beeinflusst alle folgenden, und ranghöhere oder lautere Stimmen dominieren. Durch die verdeckte, gleichzeitige Wahl bringt jede Person ihre ehrliche Einschätzung ein. Gerade die Abweichungen sind wertvoll, weil sie unterschiedliche Annahmen sichtbar machen und ein gemeinsames Verständnis erzeugen.

Zusammenhang mit Story Points und Velocity

Planning Poker ist das Werkzeug, mit dem Teams Story Points vergeben. Die geschätzten Punkte fließen in den Sprint Backlog ein und bilden über mehrere Sprints die Velocity - die durchschnittliche Menge an Story Points, die ein Team pro Sprint fertigstellt. Diese Verbindung macht Planning Poker zu einem Baustein verlässlicher Sprint- und Release-Planung: nicht die einzelne Schätzung ist entscheidend, sondern der über Zeit stabile Durchschnitt.

Abgrenzung zur absoluten Zeitschätzung

Der wichtigste Unterschied zu klassischen Zeitschätzungen in Stunden oder Tagen:

  • Relativ statt absolut: Story Points beschreiben Größe im Verhältnis zueinander, nicht die Dauer. Sie sind unabhängig davon, wer die Aufgabe umsetzt.
  • Mehrdimensional: In die Schätzung fließen Komplexität, Unsicherheit und Umfang ein - nicht nur reine Arbeitszeit.
  • Weniger Scheingenauigkeit: Die grobkörnige Fibonacci-Skala verhindert die trügerische Präzision exakter Stundenangaben.
  • Teamspezifisch: Ein Story Point bedeutet in jedem Team etwas anderes; Vergleiche zwischen Teams sind daher irreführend.

Vorteile

  • Vermeidet Anker- und Autoritätseffekte durch die verdeckte, gleichzeitige Wahl.
  • Fördert Wissensaustausch: Diskussionen bei Abweichungen decken Risiken, Annahmen und einfachere Lösungswege auf.
  • Bindet das ganze Team ein und schafft gemeinsames Verständnis der Anforderung.
  • Schnell und niederschwellig: Der Kartenmechanismus ist in wenigen Minuten erklärt und funktioniert vor Ort wie in Remote-Tools.
  • Deckt Missverständnisse früh auf: Große Abweichungen signalisieren, dass die Story noch nicht ausreichend verstanden oder zu grob geschnitten ist.

Grenzen und typische Fehler

  • Zeitaufwand bei großen Backlogs: Jede Story einzeln zu bepokern kann langwierig sein; für Massenschätzungen eignen sich schnellere Verfahren wie Team Estimation Game oder Affinity Estimation besser.
  • Punkte als Zeit missverstehen: Werden Story Points heimlich in Stunden zurückübersetzt, geht der Vorteil der relativen Schätzung verloren.
  • Druck zum Konsens: Wird auf schnelle Einigung gedrängt, unterdrücken stille Mitglieder ihre Bedenken - genau die wertvollen Abweichungen gehen verloren.
  • Fehlende Referenz-Stories: Ohne kalibrierte Vergleichs-Stories driften die Werte über die Zeit auseinander (Story-Point-Inflation).
  • Schätzung als Verpflichtung: Eine Schätzung ist eine Prognose, kein bindendes Versprechen; wird sie so behandelt, entsteht Angst vor ehrlichen Werten.

Praxistipps

  • Zu Beginn einige Referenz-Stories festlegen (z. B. "eine typische 3, eine typische 8"), an denen sich neue Schätzungen orientieren.
  • Stories, die 13 oder mehr Punkte erhalten, vor der Umsetzung aufteilen - sie sind meist zu groß für einen Sprint.
  • Bei einer "?"-Karte zuerst die offene Frage klären, statt zu raten.
  • Für verteilte Teams digitale Planning-Poker-Werkzeuge nutzen, die verdeckte Wahl und gleichzeitiges Aufdecken abbilden.
  • Den Fokus auf die Diskussion legen, nicht auf die Zahl - der eigentliche Wert entsteht im gemeinsamen Verständnis.

Richtig eingesetzt ist Planning Poker weniger ein Rätsel um die "korrekte" Zahl als ein strukturiertes Gespräch. Es macht unterschiedliche Sichtweisen sichtbar, schafft ein gemeinsames Bild der Aufgabe und liefert nebenbei die relativen Schätzungen, auf denen eine verlässliche agile Planung aufbaut.