5 1 Vote
Artikel-Rating

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.

Das Planning-Poker-Set

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

  • Diese Kartensets erhältst Du beispielsweise amazon.

  • Wenn Du Eure Karten ein wenig individueller gestalten und ein klein wenig mehr Aufwand investieren möchtest, kannst Du Dir auf MeinSpiel.de auch ein eigenes Kartenset gestalten.

  • Außerdem gibt es diverse Online-Plattformen, wie beispielsweise Scrum Poker Online, falls Euer Team vorrangig remote arbeitet.

Aufbau der Planning-Poker-Kartensets

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.)

Wie wird Planning Poker gespielt?

Der Ablauf beim Planning Poker ist relativ simpel.
0
Es gibt eine Menge Hausregeln zum Planning Poker. Hast Du bereits welche davon genutzt? Wie waren Deine Erfahrungen damit?x
  • Der Product Owner stellt eine User Story vor, deren Aufwand mit Hilfe von Story Points geschätzt werden soll.

  • Die Entwickler des Scrum Teams haben die Gelegenheit, Rückfragen zu stellen, um mehr über die User Story zu erfahren.

  • Wenn keine weiteren Fragen mehr auftauchen, legt jeder Entwickler verdeckt eine seiner Meinung nach passende Planning-Poker-Karte aus.

  • Erst wenn jeder Spieler eine Karte ausgelegt hat, werden Karten umgedreht.

  • Der Spieler, der die Karte mit den höchsten Story Points ausgelegt hat, legt dar, warum die User Story seiner Meinung nach aufwändig(er) ist.

  • Der Spieler, der die niedrigste Karte ausgespielt hat, erklärt, warum die Umsetzung der User Story seiner Ansicht nach weniger aufwändig ist.

  • Die Entwickler klären gemeinsam mit dem Product Owner offene Fragen. (Neue Erkenntnisse aus dieser Diskussion sollten bestenfalls als Akzeptanzkriterien oder wenigstens Notiz an der User Story festgehalten werden.)

  • Die User Story wird anschließend erneut mit Planning Poker geschätzt. Falls die Entwickler wieder nicht zu einer gemeinsamen Perspektive kommen, wiederholt sich der Ablauf noch ein weiteres Mal.

  • Das Ganze wird so lange wiederholt, bis alle die gleiche Planning-Poker-Karte ausgelegt haben. Danach geht’s weiter zur nächsten User Story.

Tipps für Eure erste Runde Planning Poker

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.

Schätzt so früh wie möglich

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.

Vergleicht Euer Ergebnis immer mit Referenz-User-Stories

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.

Beginnt bei der ersten Pokerrunde mit einer Referenz-Story der Größe 3 SP

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.

Vermeidet Maximalschätzungen

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.

Die Entwickler haben das letzte Wort

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.

Fazit zum Planning Poker

Auch wenn Planning Poker kein offizielles Pflichtprogramm für Scrum Teams ist, hat sich diese Methode jedoch ungemein bewährt. Zum einen gelangt Dein Team zu einer realistischen Aufwandsschätzung. Zum anderen erzeugt es den positiven Nebeneffekt eines regen Wissensaustausches innerhalb des Teams.

Falls Dein Team jedoch ganz besonders viele User Stories schätzen muss (beispielsweise vor Beginn eines Projektes), kann es sinnvoll sein, Magic Estimation statt Planning Poker zu nutzen.