Scrum Poker: Tipps und Tricks

Planning Poker wird oft als „leicht zu erlernen, aber schwer zu meistern” beschrieben. Die Mechanik ist klar: Story lesen, Karte wählen, gleichzeitig aufdecken, diskutieren, wiederholen. Aber Teams, die es rein mechanisch behandeln, verpassen den größten Teil seines Wertes. Der echte Nutzen von Planning Poker entsteht durch die Disziplin und Kultur, die man darum aufbaut. Hier sind die wichtigsten Tipps und Stolpersteine, die man im Kopf behalten sollte.

Story Points nicht in Stunden umrechnen

Dies ist der bei weitem häufigste Fehler beim Planning Poker, und er zerstört still und leise die Integrität des gesamten Schätzprozesses. Story Points messen relative Komplexität – sie sind keine verkleidete Zeiteinheit. In dem Moment, in dem das Team anfängt zu sagen „ein Story Point entspricht vier Stunden”, hat man eine Fiktion geschaffen, die kein System stützen kann.

Verschiedene Entwickler arbeiten mit unterschiedlicher Geschwindigkeit. Kontextwechsel, Code-Reviews, Meetings und unerwartete Abhängigkeiten beeinflussen die tatsächlich aufgewendete Zeit. Story Points sind darauf ausgelegt, diese Variablen zu abstrahieren. Erzwingt man eine Umrechnung, entstehen Schätzungen, die in beiden Dimensionen falsch sind – weder genaue Story Points noch genaue Stunden.

Wenn Stakeholder Liefertermine benötigen, sollte man die Velocity-Historie des Teams verwenden, um den Sprint-Abschluss zu projizieren. Das ist der richtige Weg, Story Points in zeitbasierte Prognosen zu übersetzen.

Den Prozess schützen, um Gruppendenken zu verhindern

Das gleichzeitige Aufdecken der Karten beim Planning Poker hat einen bestimmten Zweck: Anchoring zu verhindern. Anchoring bezeichnet die Tendenz, sich an der ersten gehörten Zahl zu orientieren und die eigene Schätzung unbewusst darauf anzupassen. Wenn ein Senior-Entwickler vor dem Aufdecken sagt „Ich denke, das ist eine 8”, ist der Rest des Teams bereits beeinflusst.

Das gleichzeitige Aufdecken sollte als strikte Prozessregel behandelt werden. Niemand gibt seine Schätzung preis – weder verbal noch durch Körpersprache –, bis alle bereit sind. Das ist besonders wichtig in Remote-Sessions, wo Stummschalten und ausgeschaltete Kameras unbeabsichtigt Zögern oder Sicherheit signalisieren können, bevor abgestimmt wird.

Gruppendenken ist ein reales Risiko in jedem kollaborativen Schätzprozess. Diverse, unabhängige Meinungen sind das Rohmaterial, das Planning Poker nützlich macht. Sie zu schützen ist entscheidend.

Kartenfolgen standardisieren

Teams tendieren manchmal zu inkonsistenten Kartendecks – manche Mitglieder verwenden die Standard-Fibonacci-Folge, andere eine modifizierte Version, und gelegentlich gibt es ein abweichendes „halber Punkt”-Schätzwert. Diese Inkonsistenz untergräbt die gemeinsame Sprache, auf die Planning Poker angewiesen ist.

Es sollte eine einheitliche Kartenfolge vereinbart und konsequent verwendet werden. Das klassische Fibonacci-Deck (1, 2, 3, 5, 8, 13, 21, 34, 55, 89) funktioniert für die meisten Teams gut. Wenn das Team regelmäßig sehr kleine Aufgaben hat, kann eine ½ hinzugefügt werden. Wenn nie etwas über 13 geschätzt wird, weil große Stories immer erst aufgeteilt werden, kann das Deck entsprechend gekürzt werden. Entscheidend ist, dass das Team sich einigt und alle dieselben Werte verwenden.

Online-Tools wie Scrum Poker Online ermöglichen es registrierten Nutzern, ihre Kartenwerte anzupassen – was für Teams mit nicht-standardisierten Workflows nützlich ist, aber diese Anpassung sollte eine bewusste Team-Entscheidung sein, keine individuelle.

Die richtigen Teilnehmer einbeziehen

Planning Poker liefert bessere Ergebnisse, wenn die Schätzenden auch die Ausführenden sind. Entwickler, QA-Ingenieure und UX-Designer sollten in Sessions einbezogen werden – alle, deren Arbeit von den geschätzten Stories betroffen ist. Der Product Owner sollte anwesend sein, um Fragen zu beantworten und Anforderungen zu klären, stimmt aber typischerweise nicht ab (seine Rolle ist es, das Was zu definieren, nicht das Wie zu schätzen).

Die Rolle des Scrum Masters beim Planning Poker ist die Moderation – die Session im Rahmen halten, Diskussionen timeboxen und sicherstellen, dass das gleichzeitige Aufdecken eingehalten wird. Ein guter Scrum Master muss nicht abstimmen und sollte dem Drang widerstehen, das Team in Richtung einer bestimmten Schätzung zu lenken.

Es sollte vermieden werden, Personen einzubeziehen, deren Anwesenheit die Dynamik unvorteilhaft verändert – Führungskräfte, die Teammitglieder zögern lassen, ehrlich hohe Schätzungen abzugeben, oder externe Berater, deren Schätzungen nicht den tatsächlichen Kontext und die Rahmenbedingungen des Teams widerspiegeln.

Abweichungen als Informationen begreifen

Wenn Schätzungen stark voneinander abweichen – zum Beispiel eine 2 neben einer 13 – ist der Instinkt oft, dass etwas schiefgelaufen ist. Tatsächlich ist etwas sehr Richtiges passiert. Diese Lücke signalisiert, dass zwei Teammitglieder die Story grundlegend unterschiedlich verstehen. Wer die Schätzungen mittelt und weitermacht, trägt dieses Missverständnis in den Sprint.

Stattdessen sollte man die Ausreißer um ihre Begründung bitten. Die Person mit der 2 hat dieses Problem möglicherweise bereits gelöst und kennt eine Abkürzung. Die Person mit der 13 hat vielleicht eine Abhängigkeit bemerkt, die sonst niemand gesehen hat. Beide Informationen sind wertvoll. Die folgende Diskussion ist der Moment, in dem Planning Poker seinen Wert beweist.

Fazit

Planning Poker ist eine täuschend reichhaltige Praxis. Die Mechanik ist in fünf Minuten gelernt, aber Sessions durchzuführen, die das gemeinsame Verständnis, die Schätzgenauigkeit und das Planungsvertrauen des Teams wirklich verbessern, erfordert fortlaufende Disziplin und Aufmerksamkeit. Die Umrechnung von Story Points in Stunden vermeiden, das gleichzeitige Aufdecken schützen, das Deck standardisieren, die richtigen Personen einbeziehen und abweichende Schätzungen als Chancen betrachten – wer das beherrscht, macht Planning Poker zu einem der wirkungsvollsten Werkzeuge in einem agilen Team.