Wie funktioniert Planning Poker?

Schätzungen gelingen immer dann besonders gut, wenn jede Perspektive zu einer User Story möglichst gleichberechtigt besprochen wird. Leider haben wir Menschen zum einen eine starke Tendenz zum Gruppendenken. Zum anderen werden andere Meinungen und Ansichten zu einem Thema auch oft einfach “übergebügelt”. (Der sogenannte Hippo-Effekt ist an dieser Stelle besonders erwähnenswert.) Viele agile Teams nutzen deshalb Planning Poker bzw. Scrum Poker, um Schätzungen anonym abzugeben, um beide Effekte so gut es geht zu minimieren.

Wie viele Praktiken und andere Methoden auch, ist Planning Poker lediglich eine etablierte Praxis und nicht vom Scrum Guide vorgeschrieben.

In diesem Artikel erkläre ich Dir, wie Planning Poker funktioniert. Außerdem gebe Dir ein paar Tipps an die Hand, mit denen Dein Team seine erste Pokerrunde erfolgreich meistern wird.

Um Aufwände mit Planning Poker zu schätzen, benötigst Du für jedes Mitglied Deines Scrum Teams ein Set Planning-Poker-Karten.

Jedes Kartenset bildet eine (angepasste) Fibonacci-Folge ab, um den Aufwand von User Stories mit Hilfe von Story Points (SP) zu schätzen. Viele Sets haben darüber hinaus auch Karten mit den Werten 0 und ½ sowie ein Zeichen für unendlich (∞) und eine Stop-Karte. (Oft ist das eine Kaffeetasse). Die ∞-Karte kann bei User Stories genutzt werden, die viel zu groß sind, um sie schätzen zu können. Die Stop-Karte kann jede(r) ausspielen, wenn er dem Team signalisieren möchte, dass er oder sie eine Pause benötigt.

Jeder Teilnehmer am Planning Poker hat also in der Regel 13 Karten mit folgenden Werten:

0, ½, 1, 2, 3, 5 ,8, 13, 20, 40, 100, ∞ und STOP

Manche Planning Poker Sets haben auch noch eine Fragezeichen-Karte. (Falls ein Teilnehmer überhaupt gar nicht weiß, wieviel Aufwand eine User Story haben könnte.)

Auch wenn der grundsätzliche Ablauf beim Planning Poker recht simpel ist, gibt es dennoch ein paar kleinere Fallstricke, die auf Euch lauern.

Deshalb habe ich hier ein paar Tipps für Dich zusammengestellt, die Euch dabei helfen sollen, Eure erste Pokerrunde zum vollen Erfolg zu machen.

Planning Poker ist am effizientesten, wenn die Vergabe der Story Points so früh wie möglich erfolgt. Gerade unerfahrene Teams haben eine Tendenz dazu, eine User Story erst bis ins allerletzte Detail zu besprechen, um dann eine Schätzung abzugeben. Für eine ausreichend genaue Aufwandsschätzung ist das jedoch gar nicht notwendig. Die genauen Details zu einer User Story solltet Ihr besser im Sprint Planning besprechen.

Meiner Erfahrung nach reichen 5 bis 7 Minuten für die Vorstellung und Schätzung einer User Story vollkommen aus. Sollte dann der Fall eintreten, dass die Schätzungen im Planning Poker extrem unterschiedlich sind, könnt Ihr weitere 5 bis 7 Minuten in die User Story investieren und wieder erneut schätzen.

Euer Ziel sollte es nicht sein, so viel über eine User Story zu reden, bis Ihr hundertprozentig sicher sein könnt, dass beim Planning Poker alle die gleiche Karte auslegen.

Ein (virtueller) Timer, den Ihr auf eine zuvor vereinbarte Zeit stellt, ist dabei sehr hilfreich.

Häufig beobachte ich auch, dass geschätzte User Stories nur mit User Stories verglichen werden, die ebenfalls Teil des aktuellen Backlog Refinements sind.

Es lohnt sich jedoch immer, einen Blick auf bereits abgeschlossene User Stories aus vergangenen Sprints zu werfen, damit die Werte möglichst konstant bleiben. Dort könnt Ihr eine aktuell geschätzte User Story mit User Stories vergleichen, die eine Nummer größer bzw. kleiner sind. Wenn Ihr also eine User Story mit 5 Story Points bedacht habt, vergleicht sie noch einmal mit einer alten User Story der Größe 3 und einer Story mit der Größe 8.

Manche Teams legen sogar für ein oder zwei konkrete SP-Werte Referenz-Stories fest, die sie für jedes Refinement als Vergleichsgröße nutzen.

Falls es Eure erste Pokerrunde ist und Ihr noch keine Referenz-Stories besitzt, solltet Ihr Euch für eine User Story entscheiden, bei der sich jedes Teammitglied gut auskennt.

Weist dieser User Story 3 Story Points zu.

Im weiteren Verlauf Eurer Arbeit werdet Ihr zwangsläufig User Stories haben, die kleiner sind. Wenn Ihr mit 1 SP gestartet seid, habt Ihr keine Luft mehr nach unten, wenn Ihr für Eure Referenz-Story bereits 1 SP vergeben habt.

Gerade in Scrum Teams, in denen “hauptamtliche” Tester Teil des Teams sind, kommt es sehr oft zu Maximalschätzungen. Tester haben in der Regel 1.000 Dinge im Kopf, die schief gehen können. Und vergeben deshalb meistens sehr viele Story Points. Diese Teams vergeben dann 20 SP für eine User Story, die eigentlich 13 oder sogar nur 8 SP hat, um “auf der sicheren Seite” zu sein. (Und sich später niemand beschwert.)

Um realistische(re) Schätzungen zu erzielen, kannst Du als Scrum Master mit einer kleinen Frage Hilfestellung leisten, um Maximalschätzungen zu vermeiden:

Besteht eine realistische Chance, dass diese User Story, die Ihr mit 8 SP geschätzt habt, sich im Nachhinein als User Story der Größe 13 bzw. 5 herausstellt?

Dadurch hilfst Du Deinem Team dabei, weder zu optimistisch noch zu pessimistisch zu schätzen.

Es ist ein fest verankertes Prinzip in Scrum, dass nur diejenigen Menschen Aufwände schätzen, die später auch für die Umsetzung einer User Story verantwortlich sind. Das bedeutet, dass weder der Scrum Master noch der Product Owner eine Schätzung beim Planning Poker abgeben, sondern nur die Entwickler des Teams. (Es sei denn, sie sind gleichzeitig auch Entwickler.) Trotzdem dürfen Product Owner und Scrum Master natürlich Nachfragen zu einer Schätzung stellen und ihre Sicht der Dinge darstellen.

Das letzte Wort haben jedoch immer die Entwickler.

Gelegentlich kann es vorkommen, dass Dein Team sich nicht einig darüber wird, wie viele Story Points für eine User Story vergeben werden sollen. Oder viele Teilnehmer spielen die Fragezeichen-Karte aus, um zu signalisieren, dass sie eine User Story nicht (ein-)schätzen können. Das ist ein Indiz dafür, dass entweder die Architektur Eurer Software zu komplex (oder unbekannt) ist oder den Teilnehmern notwendiges Wissen fehlt.