Mit der Einführung agiler Entwicklungsmethoden hat bei uns im Unternehmen Planning Poker als Schätzverfahren Einzug gehalten. Was genau unter Planning Poker verstanden wird, wie dieses Schätzverfahren funktioniert und welche Vorteile sich dadurch ergeben, erfahrt ihr hier.

Was ist Planning Poker?

Planning Poker ist ein standardisiertes „Schätzmeeting“, welches regelmäßig vor Beginn eines Entwicklungsabschnitts (Sprint) stattfindet. Genutzt wird dieses Verfahren von Software-Entwicklern im Rahmen von Scrum. Im Gegensatz zu klassischen Schätzmethoden wird bei Planning Poker jedoch nicht der Aufwand oder die Dauer der Umsetzung bewertet, sondern die Komplexität eines Features. Auf diese Weise entstehen zeitlose Schätzungen, die unabhängig von Erfahrung und Schnelligkeit bestimmter Personen sind. Das Ziel von Planning Poker ist, dass am Ende alle vom Product Owner vorgestellten User Stories mit sogenannten Story Points versehen sind. Auf dieser Grundlage priorisiert der Product Owner in einem weiteren Schritt sein Product Backlog.

Zurück geht das Verfahren auf den amerikanischen Softwareingenieur Barry W. Boehm. Er richtete mit der Function-Point-Analyse den Fokus weg von der Umsetzungsdauer hin zur Komplexität. 2002 entwickelte sich dann durch James Grenning das Planning Poker Spiel, das durch Mike Cohns Buch „Agile Estimating and Planning“ international berühmt wurde.

Auf den Poker Karten befinden sich folgende Zahlen: 0, 1, 2, 3, 5, 8, 13, 20, 42, 100, Pause und ein Fragezeichen. Die Werte leiten sich von der Fibonacci-Folge ab. Die Komplexität steigt mit der Höhe der Zahl. Die beiden Karten mit der Kaffeetasse und dem Fragezeichen sind Joker-Tassen und bedeuten, dass der Spieler eine Pause benötigt bzw. im Falle des Fragezeichens gar keine Ahnung hat.

Ziel eines jeden Sprints ist es, dass am Ende alle User Stories vollständig erledigt sind. Die Erfahrung hat uns gezeigt, dass User Stories deshalb ab einer gewissen Anzahl an Story Points nicht mehr in einen Sprint verplant werden sollten. Bei einem zweiwöchigen Sprint ist eine Story mit einer Komplexität von 20 bereits als hohes Risiko einzustufen. Deshalb bietet es sich an, eine solche User Story in weitere Unter-Stories zu zerlegen, um das Sprintziel nicht zu gefährden.

Wie funktioniert Planning Poker?

Ein Moderator bzw. der Scrum Master stattet das Team mit Planning Poker Karten aus. Dann stellt der Product Owner seine erste User Story (Feature) vor. Das Entwickler-Team ist an dieser Stelle aufgefordert, Rückfragen zu stellen und Risiken zu besprechen. Wichtig ist, dass alle Teammitglieder am Ende der Diskussion verstanden haben, was genau umgesetzt werden soll. Wenn keine Verständnisfragen mehr vorliegen, wird die Komplexität der ersten User Story geschätzt. Die Schätzung orientiert sich übrigens oftmals an einer bereits bekannten und geschätzten Referenzstory: „In welchem Verhältnis steht die gerade vorgestellte Story zur Referenzstory?“ Dies erleichtert die Schätzung. Jedes Teammitglied schätzt für sich allein und legt die Karte mit dem Wert nach unten auf den Tisch. Sobald alle Mitglieder fertig sind, weist der Moderator dazu an, alle Karten gleichzeitig umzudrehen. Weichen die Werte innerhalb des Teams stark ab, werden die Gründe diskutiert. Die Schätzung wird solange wiederholt, bis sich die Gruppe untereinander einig ist und einen konkreten Wert für das jeweilige Feature liefern kann.

Gerade bei cross-funktionalen Teams entstehen bei der Einführung von Planning Poker erfahrungsgemäß oftmals Diskussionen, weil Teammitglieder sich nicht in der Lage sehen, eine Schätzung abzugeben. Mögliche Ursachen können sein, dass sie sich nicht für die Umsetzung einer Story verantwortlich zeichnen oder über mangelndes Fachwissen verfügen. Es ist jedoch völlig bedeutungslos, wer welche Story später im Sprint umsetzen wird oder auf wieviel Erfahrungsschatz jemand zurückgreifen kann. Beim Planning Poker ist entscheidend, dass die wichtigsten Eigenschaften einer Story und mögliche Risiken identifiziert werden. Deshalb ist jedes Teammitglied befähigt, eine Schätzung abzugeben.

Von der Velocity zur Planbarkeit

Auch bei einem agil entwickelten Projekt möchte der Auftraggeber natürlich wissen, mit welcher Umsetzungsdauer zu rechnen ist und welche Kosten am Ende für ihn entstehen. Deshalb wird zur Release-Planung die Velocity (Geschwindigkeit) eines Teams hinzugezogen. Die Velocity eines Teams ist die Anzahl der Story Points, die während eines Sprints fertiggestellt werden. Je nach Größe des Teams, Dauer des Umsetzungsabschnitts und Erfahrung variiert die Velocity. Bei einem eingespielten Team kann jedoch auf einen Erfahrungswert zurückgegriffen werden.

Um die Dauer der gesamten Entwicklungszeit abzuschätzen, wird das komplette Product Backlog (alle User Stories, die innerhalb eines Projektes umgesetzt werden sollen) geschätzt. Anhand der durchschnittlichen Velocity lässt sich die Anzahl der benötigten Sprints berechnen.

Welche Vorteile bringt Planning Poker?

Gemeinsames Verständnis

Beim Planning Poker sind alle am Projekt beteiligten Personen anwesend: Vom Scrum Master, zum Product Owner bis hin zum Entwicklerteam. Durch die Durchsprache der einzelnen Features wird schnell klar, woran es noch hakt und welche User Stories noch einmal überarbeitet werden müssen. Unklarheiten werden also bereits vor der Umsetzung aus dem Weg geräumt und mit den Stakeholdern geklärt.

Team-Entscheidungen

Beim Planning Poker entscheidet nicht eine Person allein. Die endgültige Punktezahl ist eine Teamentscheidung. Jeder ist dazu angeregt mitzudiskutieren und jeder wird ernst genommen. Es gibt keine Hierarchien, die das Ergebnis beeinflussen. Die Schätzungen stammen vom Team und nicht den Vorgesetzten und werden somit vom Team getragen.

Schnelle Durchführbarkeit

Komplexität zu schätzen, erfordert unserer Erfahrung nach ein bisschen Übung. Anfangs fällt es vielen Menschen schwer, plötzlich nicht mehr eine Anzahl von Stunden oder Personentagen als Schätzung abzugeben. Beim Planning Poker werden Features in Relation zueinander bewertet. Dies macht das Verfahren nach einigen Runden Planning Poker in einem eingespielten Team auf Dauer einfacher und damit schneller.

Objektivität der Schätzung

Die Schätzung von Komplexität ermöglicht eine möglichst objektive Schätzung unabhängig von einer bestimmten Person. Denn im Gegensatz zur Aufwandsschätzung hängt sie nicht von der Erfahrung eines bestimmten Entwicklers oder dessen Schnelligkeit ab.

Zusammenfassend sei gesagt, dass unsere Teams mit Planning Poker nicht nur gute Schätzungen erhalten, sondern auch der Spaßfaktor nicht zu kurz kommt. Es lohnt sich also, einmal eine Runde zu pokern!