Das Planning Poker ist eine Technik um einen Aufwand für eine User Story abschätzen zu können. Beim Abschätzen eines Aufwands spielen mehrere Faktoren eine Rolle. Ein primärer Faktor ist der Mensch selbst. Jedes Teammitglied schätzt auf Grundlage der individuellen:
- Erfahrungswerte aus der Vergangenheit
- Programmierkenntnisse
- Wahrnehmung für die Aufgabe (User Story)
- Wahrnehmung für das Lösungskonstrukt
- Selbsteinschätzung (Selbstwertgefühl)
- Integration innerhalb des Teams
Jedes der vorgenannten Punkte beinflussen die Einschätzung für die Umsetzung einer User Story. Das Planning Poker kann helfen diese Faktoren zu neutralisieren und einen relativen Aufwand über die individuellen Faktoren hinweg zu Tage zu fördern.
Für eine relative Abschätzung kann man die Fibonacci Zahlen zur Hilfe nehmen. Die Fibonacci Zahlen nutzt hierbei auf der Annahme, dass eine Schätzung immer ungenau ist und je höher der Aufwand, desto ungenauer die Abschätzung wird. Es geht also bei der Abschätzung nicht einen möglichst exakte Zeitangabe zu erhalten, sondern eine möglichst präzise Aussage über den Aufwand zu erhalten. Der Aufwand misst sich hierbei nicht in Zeit, d.h. in Tagen oder Stunden, sondern in Storypoints. Wie lange eine Storypoint in der Umsetzung benötigt, kann man an Hand der Velocity berechnen.
Beim Planning Poker benötigt jedes umsetzende Team Mitglied (nicht der Scrum Master und auch nicht der Product Owner), ein Kartenset:
Die Karten mit den Zahlen sind offensichtlich die Storypoints mit den Fibonacci Zahlen. Mit der Karte auf der die Tasse abgebildet ist, fordert man eine Pause. Die Karte mit dem Fragezeichen bedeutet, dass man die User Story nicht verstanden hat und daher auch keine Schätzung abgegeben wird.
Betrachten wir nun mal genau den Ablauf eines Planning Pokers. Ein Planning Poker nutzt man in Rahmen eines Backlog Groomings oder auf der Sprintplanung 1. Teilnehmen am Planning Poker sollte das vollständige Scrum Team.Der Scrum Master sollte hierzu eine kleine Einleitung sprechen, damit allen Beteilligten klar ist, z.B. wann die Karten umgedreht werden und wann diskutiert werden sollte.
Sobald das geschehen ist, erklärt der Product Owner die einzelne User Story, ohne eine Technische Umsetzung vorzugeben. Anschliessend können Fragen gestellt werden, oder zumindest die Diskussion zwischen den Teammitgliedern darf entstehen. Der Scrum Master sollte die Zeit hierbei im Auge behalten. Jenachdem wieviel Zeit für das Meeting reserviert wurde, muss man als Scrum Master die Gruppe an einem Punkt mit der Moderation abholen zum Poker zurückführen. D.h. wenn die Diskussion ausartet, sollte man der Gruppe eine „Vorentscheidung“ anbieten und den Team Mitgliedern zum ziehen der Karten auffordern. Wenn hierbei als Ergebnis Fragezeichen oder sehr hohe Storypoints angezeigt werden, muss die Diskussion eine Runde weitergehen.
Hierbei sollte man als Scrum Master wiederum die Uhr im Auge behalten. Sollten bei der Abstimmung weniger große Differenzen zwischen den einzelnen Team Mitgliedern erscheinen, kann man die Diskussion auf einzelne Team Mitglieder beschränken. Man sollten hierbei das Team Mitglied mit der größten und der kleinsten Abschätzung auffordern zu sprechen, warum man soweit auseinander liegt. An dieser Stelle diskutieren die beiden Positionen über Umsetzung und Auswirkung auf den Aufwand. Auch qualitative Aspekte werden hierbei sicherlich diskutiert. Als Egebnis kann hierbei resultieren, dass man entweder den Aufwand mittelt oder das man nach dem Fluss der Informationen erneut die Karten spielt. Jedem sollte aber bewusst sein, wenn viele Informationen diskutiert wurde, kann das einzelne Team Mitglieder in ihrer Einschätzung beeinflussen. Daher sollte man als Scrum Master abwägen, ob man erneut schätzt oder ob man abkürzt und den Mittelwert nimmt.