Häufige Fehler beim Scrum Poker – und wie man sie vermeidet

Planning Poker ist eine der wirkungsvollsten agilen Schätztechniken – aber sie ist kein Selbstläufer. Teams, die sie als bloße Pflichtübung behandeln und nicht als echtes kollaboratives Werkzeug, erleben häufig, dass ihre Schätzungen von der Realität abweichen, die Sessions zu lang werden oder die Teammitglieder das Interesse verlieren. Die häufigsten Fehler zu kennen ist der erste Schritt zu Schätzsessions, die tatsächlich funktionieren.

Fehler 1: Unzureichende Einführung und Onboarding

Viele Teams führen Planning Poker ein, ohne die zugrunde liegenden Prinzipien ausreichend zu erklären. Neue Teammitglieder verstehen möglicherweise nicht, warum die Fibonacci-Folge verwendet wird, was Story Points wirklich bedeuten oder wie man Komplexität von Aufwand unterscheidet. Das führt zu inkonsistenten Schätzungen von Person zu Person – was den gesamten Sinn der Übung untergräbt.

So vermeidet man es: Vor der ersten Planning-Poker-Session mit neuen Teammitgliedern sollte Zeit investiert werden, um die Grundprinzipien zu erklären. Eine Übungssession mit gut verstandenen Stories aus vergangenen Sprints hilft neuen Mitgliedern, ihre Schätzungen an den etablierten Normen des Teams zu kalibrieren. Auch periodische Auffrischungen sind sinnvoll – besonders nach Änderungen in der Teamzusammensetzung.

Fehler 2: Schlecht definierte Arbeitspakete

Eine vage User Story zu schätzen ist Raterei, keine Schätzung. Wenn die Akzeptanzkriterien unklar sind, wenn die Story mehrere Systeme oder Teams umfasst oder wenn die „Definition of Done” mehrdeutig ist, fehlt dem Team eine gemeinsame Vergleichsgrundlage. Schätzungen unter diesen Bedingungen variieren stark – und selbst wenn eine Zahl gefunden wird, spiegelt sie die Realität kaum wider.

So vermeidet man es: Eine „Definition of Ready” für User Stories sollte eingeführt werden, bevor sie in eine Schätzsession aufgenommen werden. Stories benötigen klare Akzeptanzkriterien, bekannte Abhängigkeiten und genügend Kontext für eine sinnvolle Diskussion. Der Product Owner sollte beim Planning Poker anwesend sein, um Fragen in Echtzeit zu klären.

Fehler 3: Persönliche Einflussnahme auf andere

Planning Poker ist gezielt so konzipiert, dass es Anchoring verhindert – die Tendenz, sich von der ersten Zahl, die man hört, beeinflussen zu lassen. Das gleichzeitige Aufdecken der Karten ist der Mechanismus, der das sicherstellt. Aber Teams untergraben diesen Mechanismus häufig, indem sie Senior-Entwicklern, Tech Leads oder redefreudigen Teammitgliedern erlauben, ihre Schätzung vor dem Aufdecken der Karten zu teilen.

So vermeidet man es: Das gleichzeitige Aufdecken der Karten sollte als unveränderliche Regel behandelt werden. Das Team sollte regelmäßig daran erinnert werden, dass es in der privaten Auswahlphase darum geht, eine unabhängige Meinung zu bilden. Moderatoren sollten aktiv verhindern, dass konkrete Zahlen vor dem Aufdecken diskutiert werden. Wenn die Schätzung einer bestimmten Person die Diskussion immer wieder dominiert, sollte hinterfragt werden, ob diese Person zu ausführlich erklärt oder ob andere unnötig nachgeben.

Fehler 4: Zu schnell durch die Diskussion huschen

Wenn Schätzungen stark voneinander abweichen, liegt der Reflex oft darin, die Mitte zu nehmen und weiterzumachen. Das fühlt sich effizient an, verschenkt aber den wertvollsten Teil von Planning Poker: das Gespräch, das eine Meinungsverschiedenheit auslöst. Derjenige, der als Einziger eine 13 schätzt, während alle anderen 3 zeigen, hat möglicherweise eine Abhängigkeit bemerkt, die sonst niemand erkannt hat.

So vermeidet man es: Abweichende Schätzungen sollten als Signal behandelt werden, nicht als Problem. Den Schätzern mit den höchsten und niedrigsten Werten sollte die Gelegenheit gegeben werden, ihre Begründung darzulegen – ohne Druck. Ein Timeboxing – drei bis fünf Minuten pro Story – hält Diskussionen produktiv, ohne sie abzuwürgen. Das Ziel ist nicht Einigkeit um der Einigkeit willen, sondern ein gemeinsames Verständnis.

Fehler 5: Schätzungen als verbindliche Zusagen behandeln

Der wohl schädlichste Fehler ist es, Story-Point-Schätzungen als Versprechen zu behandeln. Wenn Schätzungen genutzt werden, um Teammitglieder für Lieferzeitpläne verantwortlich zu machen, wird der Schätzprozess defensiv. Entwickler beginnen, ihre Schätzungen aufzublähen, um einen Puffer zu schaffen – was den Zweck der Übung zunichtemacht und das Vertrauen mit Stakeholdern erodiert.

So vermeidet man es: Das Prinzip sollte fest verankert werden: Schätzungen sind Prognosen, keine Verpflichtungen. Story Points messen relative Komplexität zu einem bestimmten Zeitpunkt, basierend auf dem aktuellen Wissensstand des Teams. Wenn sich Anforderungen ändern und Unbekanntes geklärt wird, sollten Schätzungen entsprechend aktualisiert werden. Eine Kultur zu schaffen, in der Nachschätzungen normal sind und nicht als Versagen wahrgenommen werden, ist entscheidend.

Fazit

Planning Poker ist ein mächtiges Werkzeug, wenn es durchdacht eingesetzt wird – aber seine Wirksamkeit hängt vollständig davon ab, wie das Team damit umgeht. Durch eine solide Einführung, klar definierte Stories, die Wahrung des gleichzeitigen Aufdeckens, die ernsthafte Auseinandersetzung mit abweichenden Schätzungen und die Behandlung von Schätzungen als lebendige Näherungswerte statt als feste Verträge kann das Team Planning Poker von einer routinemäßigen Formalität in einen echten Treiber gemeinsamen Verständnisses und besserer Planung verwandeln.