Tipps / Tricks für Planning Poker

Wir empfehlen mit Planning Poker® in der Standardvariante zu starten, so wie es unsere Anleitung beschreibt. Dieses Vorgehen hat sich in unserer Praxis bewährt. Abhängig vom konkreten Kontext haben wir ungünstige Entwicklungen beobachtet, auf Grund derer die agile Schätzung mit Planning Poker® nicht so effizient oder nicht so effektiv wie gewünscht funktioniert hat. Für den Umgang mit diesen Entwicklungen haben wir die nachfolgenden Tipps & Tricks zusammengetragen.
 

Beobachtung
Tipp / Trick

Dem Team fällt es schwer sich auf eine Referenzstory zu einigen, da sich nicht alle vorstellen können, wie diese umzusetzen wäre.

Diese Beobachtung macht man häufig dann, wenn die Fähigkeiten im Team sowie die Stories sehr heterogen sind.

Abhilfe leistet hier die Schätzung mehrerer Referenzstories (5-10) mit dem Ziel, dass viele im Team viele Referenzstories verstehen sollten, aber nicht jede Referenzstory von allen verstanden werden muss. Die Referenzstories sollten idealerweise im Bereich von 1 bis 8 Story Points gestreut liegen, sodass „genauso groß wie“- und „doppelt so groß wie“-Schätzungen möglich sind. Auf Basis des Bauchgefühls können diese Referenzstories ebenfalls mit Planning Poker® bepunktet werden. Ggf. sollten pro Referenzstory mehrere Runden geschätzt werden, um eine Konvergenz der gelegten Story-Point-Bewertungen zu erreichen. Sind die gelegten Bewertungen stabil, sollte der Median gewählt werden.

Die Schätzung mutmaßlich umsetzungsbereiter Stories dauern regelmäßig sehr lange.

Falls die Schätzungen lange dauern, weil die Team-Mitglieder lange über Umsetzungsvarianten diskutieren, empfiehlt es sich Time Boxes einzusetzen. Hierbei wird das Planning Poker® moderiert, z.B. vom Scrum Master. Dieser stellt für den Diskussionsteil jeder Runde einen Countdown ein. Nach dem Ablauf des Countdown wird die Diskussion sofort beendet und die Mitglieder legen ihre Schätzkarten ab. Eine Time-Box-Empfehlung sind 3 Minuten vor der ersten Schätzrunde,  2 Minuten vor der zweiten Schätzrunde und 1 Minute vor der dritten Schätzrunde. Mit der „?“-Karte kann einmalig eine Diskussions-Time-Box von 5 Minuten vor der zweiten oder dritten Runde erspielt werden. Auf diese Weise sinkt der Zeitbedarf pro Story auf ≤ 10 Minuten. Der Scrum Master sollte beobachten, ob Team und Product Owner bzw. Stakeholder sich in angemessenem Umfang (80-20-Prinzip) über die Story ausgetauscht haben.

Alternativ kann zunächst eine gröbere agile Schätzmethode wie Magic Estimation oder das Estimation Game eingesetzt werden. Nur die unklaren und strittigen Stories werden anschließend mit Planning Poker® geschätzt.

Falls die Schätzrunden regelmäßig lange dauern, weil die Stories nicht gut verständlich, unkonkret oder zu groß sind, sollte der Product Owner diese verfeinern. Hier kann ein Sparring mit einem Team-Mitglied helfen, um mit verständlich formulierten Stories vorbereitet in die Schätzung mit dem Gesamtteam zu gehen.

Die obige Empfehlung bezieht sich auf Stories, von denen der Product Owner glaubt, dass sie bereit zur Umsetzung sind. Hiervon ausgenommen sind Stories, die noch weiter verfeinert oder vereinfacht werden müssen. Diese inhaltliche Arbeit muss in größeren Time Boxes erledigt werden, ggf. auch außerhalb der Schätzrunde mit dem gesamten Team. Für diese Arbeit sollte der Product Owner das Feedback des Teams aufnehmen.

Punkte-Inflation: das Team schätzt gleichartige Stories höher als früher.

Die Punkte-Inflation ist immer ein ernst zu nehmendes Symptom, dessen Ursache ergründet und beseitigt werden muss. Gründe können technische Schulden im Team sein, zu große Abhängigkeit von Dritten oder es fehlen (nun) bestimmte Fähigkeiten für die Umsetzung.

Technische Schulden und Hindernisse: Das “Scrumming the Scrum”-Pattern schlägt vor, für das drängendste Problem eine möglichst kompakte Abhilfe-Story zu formulieren und diese im nächsten Sprint anzugehen.

Fehlende Fähigkeiten sind ein spezielles Hindernis. Zur Beseitigung sollten Puffer vorgesehen werden, in denen das Team die Fähigkeiten erlernt. Wenn eine ganze Rolle nicht ausreichend gut ausgefüllt werden kann, muss das Team sich ggf. um ein weiteres Mitglied erweitern.

Abhängigkeit von Dritten: der Product Owner sollte prüfen, ob er mit den Stakeholdern vereinbaren kann, dass diese während der Umsetzung für Klärungen kurzfristig verfügbar sind.

Während des Planning Poker® kommt es nur selten zu Diskussionen über die gelegten Schätzungen.

Diese Beobachtung kann verschiedene Ursachen haben:

Es handelt sich um ein sehr eingespieltes und homogenes Team, das tief in der Materie steckt und somit in der Lage ist, homogene Schätzungen abzugeben. Es sollte aber kritisch hinterfragt werden, ob das wirklich der Fall ist oder ob doch eine andere Ursache vorliegt. Schließlich ist ein Ziel des Planning Poker® über die Diskussion ein gemeinsames Verständnis zu erzeugen.

Für die Schätzung wurde ein zu kleiner Zahlenraum gewählt (z.B. nur die T-Shirt-Größen S, M und L). Dadurch ist es ziemlich wahrscheinlich, dass viele Teammitglieder gleiche Karten legen, auch wenn sie sich damit nicht sicher sind. Außerdem können sich so schüchterne Mitglieder leichter der Diskussion entziehen, indem sie nur den mittleren Wert legen und somit die Abweichungen nie groß sind. In diesem Fall sollte der Zahlenraum für die Schätzung erweitert werden, so dass mindestens fünf oder sechs Optionen verfügbar sind.