So funktioniert Planning Poker

Planning Poker ist ein Verfahren zur Aufwandsschätzung im Team. Jede Person bekommt dieselben Zahlenkarten, gemeinsam wird eine User Story besprochen, und dann zeigen alle ihre Karte im selben Augenblick. Wer weit oben oder weit unten liegt, begründet seine Wahl, danach wird noch einmal abgestimmt. Der Trick steckt im gleichzeitigen Aufdecken: Eine Zahl, die vorher niemand gehört hat, kann auch niemanden beeinflussen. In einer gewöhnlichen Besprechung dagegen setzt sich erfahrungsgemäß oft die erste Zahl durch, die im Raum fällt, gerade wenn sie von jemandem mit Gewicht kommt.

Von Delphi zum Kartendeck

Die Idee, Fachleute unabhängig voneinander schätzen zu lassen und die Ergebnisse erst danach zusammenzuführen, ist älter als die agile Softwareentwicklung. In den 1950er- und 60er-Jahren entwickelte die RAND Corporation die Delphi-Methode. Die Befragten geben ihre Einschätzung anonym ab, erhalten eine Zusammenfassung der Gruppenergebnisse und überarbeiten ihre Antwort in weiteren Runden. In den 1970er-Jahren machten Barry Boehm und John Farquhar daraus Wideband Delphi, eine Variante für Softwareprojekte, bei der zwischen den Runden diskutiert wird.

Planning Poker vereinfacht das Ganze. James Grenning stellte die Technik 2002 in einem kurzen Aufsatz vor; ihm ging es um eine Release-Planung, die sich nicht in endlosen Schätzsitzungen verliert. Breiter bekannt wurde sie durch Mike Cohns Buch Agile Estimating and Planning aus dem Jahr 2005, das Planning Poker in einem Abschnitt des Kapitels über Schätztechniken beschreibt. Heute schätzen viele Teams damit die Story Points ihres Backlogs.

Ablauf einer Schätzrunde

1. Karten verteilen. Verbreitet ist eine angepasste Fibonacci-Reihe: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ergänzt um „?“ und eine Kaffeetasse. Warum die Abstände nach oben größer werden, erklärt die Seite zur Fibonacci-Skala.
2. Story vorstellen. Der Product Owner erläutert, welches Problem gelöst werden soll und woran man erkennt, dass die Story fertig ist.
3. Rückfragen klären. Gefragt wird, bis die Größe einschätzbar ist. Die technische Lösung muss dabei noch nicht feststehen.
4. Verdeckt wählen. Jede Person legt ihre Karte, ohne Kommentar und ohne Tendenzen anzudeuten.
5. Gleichzeitig aufdecken.
6. Nah beieinander: notieren. Zeigen die Karten 3, 3, 2 und 3, fragt die Moderation kurz, ob jemand mit der 3 nicht leben kann, und trägt sie ein.
7. Weit auseinander: nachfragen. Die Personen an den beiden Enden erklären, was sie bei ihrer Karte vor Augen hatten. Danach wählen alle erneut verdeckt.

Meist genügen ein bis zwei Durchgänge. Kommt das Team auch dann nicht zusammen, liegt das selten an den Schätzenden. Entweder ist die Story unklar, oder sie bündelt mehrere Vorhaben, die getrennt geschätzt werden sollten.

Wer schätzt? Die Personen, die die Story umsetzen werden, also Entwicklung, Test und je nach Team auch UX. Der Product Owner sitzt in der Runde, um Fragen zu beantworten; eine eigene Karte legt er in den meisten Teams nicht. Für Führungskräfte, die zuhören, gilt dasselbe.

Beispiel: der Glasschaden

Ein Team entwickelt das Kundenportal eines Kfz-Versicherers. Die Story für die Runde lautet: „Als Versicherungsnehmerin möchte ich einen Glasschaden online melden und Fotos der Scheibe hochladen, damit ich nicht bei der Hotline anrufen muss.“

Die Product Ownerin ergänzt, dass es für Hausratschäden bereits ein Online-Formular gibt. Auf Nachfrage bestätigt sie, dass bis zu fünf Fotos möglich sein sollen und die Meldung direkt bei der Schadenbearbeitung landen muss.

Vier Entwicklerinnen und Entwickler wählen. Aufgedeckt wird 3, 5, 3, 13.

Tobias hat eine der beiden 3er gelegt, Svenja die 13. Die Moderatorin bittet die beiden, ihre Sicht zu schildern.

Tobias: „Das Hausratformular können wir fast eins zu eins übernehmen. Ein paar andere Felder, ein Upload, fertig.“

Svenja: „Die Hausratmeldungen landen per Mail bei der Sachbearbeitung. Kfz-Schäden laufen über das Bestandssystem, und Fotos müssen dort über die alte Archivschnittstelle eingespielt werden, inklusive Virenprüfung. Die Schnittstelle hat letztes Jahr zwei Wochen gekostet, als wir die Unfallberichte angebunden haben.“

Die Product Ownerin bestätigt, dass die Meldung im Bestandssystem ankommen muss. Zweite Runde: 8, 8, 13, 8.

Eine 8 für das Ganze trägt das Team trotzdem nicht ein. Schon das Gespräch nach der ersten Runde hat gezeigt, dass in der Story zwei verschiedene Vorhaben stecken, also wird sie geteilt: die Meldung ohne Fotos, die als strukturierter Datensatz ins Bestandssystem geht, und der Foto-Upload über die Archivschnittstelle. Beide Teile werden gleich im Anschluss neu geschätzt, die Meldung mit 5, der Upload mit 8. Ohne verdeckte Abstimmung hätte Tobias’ „fast eins zu eins“ vermutlich den Ton gesetzt, und die Archivschnittstelle wäre erst im Sprint aufgefallen.

Fünf Stolperfallen

Die vorweggenommene Zahl

Schon ein „Das kennen wir doch vom Hausratformular“ kurz vor dem Aufdecken zieht die Schätzungen nach unten. Am physischen Tisch liegen die Karten deshalb mit der Rückseite nach oben. Online muss das Werkzeug die Werte bis zum Aufdecken zurückhalten, am besten so, dass sie vorher gar nicht erst an die Browser der anderen gehen.

Hierarchie im Raum

Wer neu im Team ist, richtet sich gern nach der Einschätzung der Teamleitung, spätestens in der zweiten Runde. Offen zu widersprechen, fällt schwer, wenn die erfahrenste Person anderer Meinung ist. Die Moderation kann gegensteuern, indem sie grundsätzlich zuerst die Personen mit der höchsten und der niedrigsten Karte sprechen lässt, egal wer das ist. Im Beispiel oben kam der entscheidende Hinweis auch nicht aus der Mehrheit.

Unreife Storys

Wenn auf zentrale Fragen niemand eine Antwort hat, entsteht beim Abstimmen trotzdem eine Zahl. Sie wirkt genau und sagt wenig. In so einem Fall ist „?“ die ehrlichere Karte, und die Story geht zurück ins Refinement. Was die Karten ohne festen Wert bedeuten, steht auf der Fibonacci-Seite.

Median statt Gespräch

Durchschnitt und Median helfen, eine Runde einzuordnen. Als Ergebnis taugen sie erst, wenn die Karten nah beieinanderliegen. Bei 2, 5 und 13 ergäbe der Median eine saubere 5, und die Frage, was die Person mit der 13 weiß, bliebe ungestellt.

Diskussionen ohne Ende

Das Gegenstück zum vorschnellen Eintragen ist die Story, an der sich das Team eine halbe Stunde lang festbeißt. Oft steckt dahinter eine Architekturfrage, die sich am Schätztisch gar nicht entscheiden lässt. Manche Teams vereinbaren deshalb eine Obergrenze pro Story, etwa eine Viertelstunde. Ist sie erreicht, wird die Story geparkt, und zwei, drei Leute klären die offene Frage bis zum nächsten Termin in kleiner Runde.

Schätzen im verteilten Team

Im Videocall fehlt vor allem der Moment, in dem alle ihre Karten gleichzeitig umdrehen. Improvisierte Lösungen haben ihre Tücken. Im Chat sieht man die ersten Zahlen, bevor man selbst tippt, und bei „Auf drei halten alle die Finger in die Kamera“ schauen manche erst, was die anderen zeigen.

Besser funktioniert ein Online-Raum, in dem jede Person für sich wählt und erst das Aufdecken alle Karten zeigt. Die Moderation schickt den Link in den Meeting-Chat oder hinterlegt ihn gleich in der Serieneinladung. Nach 24 Stunden ohne Aktivität wird der Raum zwar geleert, Namen und Stimmen sind dann weg, derselbe Link funktioniert aber weiter und öffnet einen leeren Raum. Während der Runde teilt die Moderation den Bildschirm mit dem Ticket, damit alle über denselben Text sprechen, und sieht im Raum, wer noch nicht gewählt hat.

SprintPoker ist für genau diesen Ablauf gebaut und läuft im Browser ohne Anmeldung; Einzelheiten stehen auf der Seite Über uns.

Dass die Konzentration nachlässt, merkt man am Bildschirm schlechter als am Tisch. Dafür gibt es die Kaffeekarte; wie man mit ihr umgeht, steht auf der Fibonacci-Seite.

Und was hat das mit Scrum zu tun?

Planning Poker gehört zu keinem bestimmten Framework, wird aber besonders häufig in Scrum-Teams eingesetzt. Wann dort geschätzt wird, wie sich Backlog-Refinement und Sprint-Planung die Arbeit teilen und welche Rolle der Scrum Master spielt, beschreibt die Seite zu Scrum Poker.