Mit Planning Poker richtig Schätzen lernen

Während meiner Arbeit in Scrum-Teams stelle ich immer wieder fest, dass viele Softwareentwickler zu geringen Fokus auf das sogenannte „Planning Poker“ legen. Dabei ist es ein sehr wichtiges Mittel in der Ausarbeitung von User Stories. Denn hier wird das gemeinsame Verständnis für Anforderungen und Akzeptanzkriterien vertieft und alle Teammitglieder können ihre Perspektive mit einbringen.

Die Methode Planning Poker

Beim „Planning Poker“ handelt es sich um eine einfache Vorgehensweise, mit der mehrere Entwickler als Team möglichst unvoreingenommen eine Schätzung zur Komplexität von User Stories oder Tasks abgeben können.

Wichtig dabei: es geht nicht um den zeitlichen Aufwand, der zur Findung einer Lösung und deren Implementierung benötigt wird. Es geht vielmehr um das gemeinsame Verständnis sowie um eine erste Abschätzung der Schwierigkeiten, welche die Umsetzung einer User Story begleiten könnten.

Vergleichbar mit einem Labyrinth, in das man sich als Softwareentwickler auf dem Weg zur fertigen Implementierung eines neuen Features begibt, bedeutet Komplexität in diesem Kontext, wie klar dieser Weg bereits vor uns liegt.

• Haben wir das Gefühl, bereits den Weg durch das Labyrinth zu kennen? Ist uns bekannt, wann wir in welche Richtung abbiegen müssen, auch wenn der Weg kompliziert scheint? Oder liegt noch der „Fog of War“ über unserem Labyrinth?
• Kennen wir Eingang und Ausgang des Labyrinths? Wissen wir, wo es losgeht und wo wir am Ende ankommen wollen? Oder ist noch nicht klar, was genau in der User Story gefordert wird?
• Komplexe Themen können oft trotzdem in kurzer Zeit technisch umgesetzt werden, sofern der Weg klar ist. Ebenso können vermeintlich einfache Aufgaben manchmal einen hohen Aufwand bedeuten, selbst wenn der Weg klar scheint.
• „Aufwand“ kann natürlich auch „zeitlicher Aufwand“ bedeuten, aber nicht ausschließlich. Benötigen wir externe Ressourcen, um die gewünschte Lösung umsetzen zu können? Haben wir das nötige Wissen verfügbar, fachlich wie technisch?
• Wie ist der Kontext unserer Problemlösung? Welchen Risiken sehen wir uns gegenüber? Müssen wir für eine Anpassung die Hälfte des bereits fertigen, existierenden Codes umschreiben, oder können wir an wenigen Stellen leicht andocken?
• Wie verhält sich das Risiko, durch ein neues Feature bereits umgesetzte und fertige Teile unserer Software zu beeinträchtigen? Je mehr Abhängigkeiten, desto komplexer kann unsere Implementierung werden.

Diese und ähnliche Fragen beschäftigen sich vor allem mit der Komplexität und nicht mit dem Zeitbedarf zur Implementierung einer User Story.

Maßstab für Komplexität

Anders als echte Pokerkarten verwendet man für Planning Poker klassisch oft Fibonacci-Zahlen als Werte. Doch warum gerade diese Zahlenfolge?

Weil sie auf den Vorgängern aufbaut, zum Beispiel 2 + 3 = 5. Die Interpretation: kleine Aufgaben sind leichter schätzbar, während es bei größeren Aufgaben immer schwieriger wird und somit die Komplexität stark zunimmt.

Die Zahlenwerte sollen absichtlich nichts mit Zeitaufwand zu tun haben, sondern geben einen Maßstab für die Komplexität an. Hinzu kommen einige Sonderkarten – sozusagen Joker – wenn ein Entwickler keine Schätzung abgeben kann.

Gemeinsames Verständnis für Komplexität

Schätzt man eine Weile im Team immer wieder nach dieser Methode, so entwickelt sich relativ schnell ein gemeinsames Grundgefühl dafür, wo genau die Komplexität in einem Projekt liegt. Es handelt sich lediglich um eine Schätzung; während der Implementierung kann sich also abweichend eine andere Komplexität ergeben. Das Team lernt daraus und kann die nächsten User Stories auf Basis der vorherigen Erfahrungen wieder etwas realistischer einschätzen.

In manchen Teams schätzt man auch mit weniger abstrakten Größen wie beispielsweise T-Shirt Sizes in S, M, L und XL. Meiner Erfahrung nach ist das jedoch oft zu grob in einem detaillierten Planning, zudem lässt es sich mit numerischen Werten leichter rechnen. Für Agile Methoden wie „Magic Estimation“ können T-Shirts als Maßstab sinnvoll sein, ich bevorzuge jedoch die klassische Variante mit Fibonacci-Zahlen.

Interpretationen der Fibonacci-Zahlen

Oft verwendet man als Referenz früher geschätzte Stories, um so eine Relation der Aufwandsschätzungen untereinander zu erhalten. So kann man sich leichter die Frage stellen, ob eine bestimmte User Story eher weniger, gleich viel oder mehr an Aufwand bedeutet – im Vergleich zu einer früher bereits implementierten Referenz-Story. Übliche Interpretationen der Fibonacci-Zahlen sehen so aus:

Oft findet man auch Werte größer als 13 auf Karten für Planning Poker. Nach meiner Erfahrung definieren viele Scrum-Teams aber eine 8 oder 13 als größten möglichen und erlaubten Wert für die Komplexität einer User Story, die das Team in einem Sprint mit zwei Wochen erfolgreich beginnen und auch beenden kann. Diese Regel beruht letztlich auf Erfahrungswerten eines Teams.

Eine 13 bedeutet in diesem Kontext meist, dass die User Story in einem Sprint nicht umsetzbar ist und daher besser in zwei bis drei kleinere Stories geteilt werden sollte. Ein Vorgehen, dass sich immer wieder als sinnvoll herausgestellt hat.

Sonderkarten

Es gibt oftmals auch Sonderkarten im Kartendeck:

• Fragezeichen: Ich habe keine Ahnung, was ich tun muss, um das zu implementieren. Mir fehlt vielleicht benötigtes Fachwissen oder es fehlen Informationen über den Produktkontext.
• Kaffeetasse: Das ist mir grade zu viel, ich brauche eine Pause.
• Unendlich: Die Aufgabe ist zu komplex und kann so nicht erfolgreich umgesetzt werden. Es ist zunächst Rücksprache mit dem Product Owner für eine Überarbeitung und Konkretisierung der User Story notwendig.

Wie man an diesen Aussagen bereits erkennen kann, ordne ich den Fibonacci-Zahlen keinen konkreten Zeitaufwand zu. Denn wie bereits erwähnt geht es uns um die Komplexität beim Planning Poker.

Zeitaufwand vs. Komplexität

Dennoch wird man als Team natürlich auch Erfahrungen zum Zeitaufwand in Relation zu Story Points sammeln:

Der Forecast zur benötigten Zeit ergibt sich in Scrum-Projekten auf Basis der vorhandenen Erfahrungen aus früheren Sprints. Dort entstehen Daten die beispielsweise zeigen, wie viele Story Points (das sind hier die Fibonacci-Zahlen) im Team mit wie vielen Entwicklern umgesetzt wurden.

In Scrum nennt man das die „Sprint Velocity“. Auf Basis dieser Datenwerte kann der Product Owner einen Forecast erstellen, in welcher Zeit das Team voraussichtlich beispielsweise ein Epic mit mehreren User Stories fertiggestellt haben wird.

Ablauf einer Pokerrunde

Je nach Teamkonstellation stellt der Product Owner oder ein Entwickler die zu schätzende User Story inhaltlich nochmal kurz vor. Im Anschluß werden alle Teilnehmer aufgefordert, verdeckt ihre Auswahl zu treffen und die entsprechende Karte aus dem Planning-Poker-Spiel bereit zu halten.

⤿Alle Entwickler drehen auf ein Zeichen hin gleichzeitig ihre Karten um. Es ist wichtig, dass die Abstimmung verdeckt erfolgt und sich keiner von den Kollegen beeinflussen lässt. Nehmen Entwickler remote teil, kann ein Tool verwendet werden, das online eine Stimmabgabe ermöglicht. Diese Stimmen werden dann ebenfalls zum Ergebnis gezählt.

⤾Als Ergebnis wird man einen Mix aus kleinen und großen Zahlenwerten von verschiedenen Entwicklern erhalten. Jeder Wert hat seine Berechtigung! Nun gilt es herauszufinden, wie man sich gemeinsam auf einen Wert einigen kann. Jede Meinung zählt!

⤿Ein Entwickler mit einem kleinen Poker-Wert stellt seine Gedanken und Begründung dem Team vor, ebenso bringt sich ein Entwickler mit einem sehr hohen Wert in die Diskussion ein. Es werden also Meinungen gegenübergestellt, die entgegengesetzte Positionen in der Schätzung einnehmen.

⤾Nach Austausch der Meinungen und kurzer Diskussion stimmen alle Entwickler erneut ab. Sofern man immer noch große Differenzen in den Schätzungen erhält, wiederholt sich die Diskussion, bis sich die Mehrheit des Teams auf einen Wert einigt.

⤿Man kann Schätzungen der anderen im Verlauf dieser Diskussion entweder mittragen ohne sie für sich zu übernehmen oder sich auch umstimmen lassen und seine Zustimmung geben. Wichtig ist, dass alle Meinungen gehört werden und in die Schätzung einfließen.

⤾Durch den Austausch und die Einigung auf einen gemeinsamen Wert entsteht etwas, das in Scrum-Projekten psychologisch wichtig und wertvoll ist: Engagement der Entwickler für das Projekt und zur skizzierten Implementierung. Es entsteht eine gemeinsame Vorstellung von der Aufgabe, die im Team umgesetzt werden soll.

Agilität (er)leben

Mut zur eigenen Meinung! Die agile Softwareentwicklung lebt davon, dass jeder Entwickler sich individuell einbringen kann, darf und auch soll. Es gibt kein „falsch“ oder „richtig“ beim Planning Poker:

1. Einzelne abweichende Schätzungen

Einzelne Entwickler haben eine deutlich abweichende Schätzung, beispielsweise zieht jemand die Karte mit der Eins und alle anderen eine Fünf. Wie kann man dies interpretieren? Vielleicht sieht der Entwickler mit der Eins eine einfache Lösung, die den anderen entgangen ist. Aber es kann auch sein, dass ihm Informationen fehlen und er somit zu einer falschen Einschätzung gelangt ist. Der Austausch und die Diskussion „seiner Eins“ mit „einer anderen Fünf“ wird das zeigen und im Ergebnis zu mehr gemeinsamem Verständnis der User Story führen.

Die meisten Entwickler zeigen kleine Werte, nur ein Entwickler hat eine 13 gezogen. Sieht er die Dinge vielleicht zu kompliziert? Oder hat er einen Aspekt der User Story entdeckt, der den anderen bisher entgangen ist? Auch hier wird die Begründung „einer Eins oder Zwei“ und der Vergleich mit den Argumenten für „seine 13“ zu mehr Klarheit führen.

2. Komplett unterschiedliche Schätzungen

Alle Entwickler haben verschiedene Werte aus nahezu der gesamten Skala gezogen. Das ist meistens ein Zeichen dafür, dass zu Inhalt und Umsetzung einer User Story noch viele Fragen offen sind. Dies führt zu mangelnder Klarheit bei den Entwicklern und ist letztlich ein Risiko für eine erfolgreiche Implementierung. Eine solche User Story sollte zunächst vom Product Owner überarbeitet werden, bevor sie ihren Weg zurück ins Refinement zur Schätzung findet. Oder die offenen Fragen lassen sich bereits kurz im Refinement klären.

3. Unklarheit über die Produktvision

Schätzen einzelne Entwickler allgemein oft deutlich höher oder niedriger als ihre Kollegen, fehlen ihnen vielleicht noch Informationen oder technisches Wissen für die Umsetzung. Auch hier hilft Planning Poker weiter, um diese Schwierigkeiten aufzudecken und dann für Ausgleich zu sorgen. Vielleicht muss das Onboarding verbessert werden? Oder die Product Owner stellen nochmals ihre Produktvision vor? Denn möglicherweise ist die Vision, was für eine Software genau entstehen soll, bei einigen Mitgliedern des Teams noch unklar und bedarf daher einer Schärfung.

Fallstricke

Irgendwann werden sich die Schätzungen einpendeln und es können mehr User Stories auf diese Art in kürzerer Zeit geschätzt werden. Vertrauen im Team entsteht auch dadurch, dass man die Perspektiven und Fähigkeiten der einzelnen Entwickler wahrnimmt und nachvollziehen kann. Doch es kann auch manches schief laufen beim Planning Poker:

• Man versucht, die eigene Meinung zurück zu halten. Es überwiegt die Angst, zuzugeben dass eine User Story nicht verstanden wurde oder das eigene Wissen zur Umsetzung fehlt. Hier hilft eine Vertrauenskultur, die es in Agilen Projekten zu etablieren gilt. Fehler gehören in Agilen Projekten dazu, noch mehr jedoch ein positiver Umgang mit diesen Fehlern.
• Entwickler warten auf die Meinung des „informellen Anführers“, der meinungsbildend vorangeht. Hierdurch gehen wertvolle andere Meinungen und Perspektiven verloren. Und ebenso Commitment, denn Entwickler geben Verantwortung für (Fehl)entscheidungen an andere ab. Es geht aber darum, dass sich jeder in den Ablauf zur Entscheidungsfindung einbringt und sich darin auch wiederfindet.

Umdenken ist angesagt

Es erfordert einiges an Mut, die eigenen Perspektiven in einem Softwareprojekt darzulegen. Oder zugeben zu können, etwas noch nicht verstanden zu haben. In diesem Kontext spricht man auch von der „Psychological Safety“ in Scrum.

Als Belohnung erhält man Komplexitätsschätzungen mit mehr Bezug zur Realität und mehr Verlässlichkeit. Und das Wachsen eines Entwicklerteams, in dem Werte wie gegenseitiges Vertrauen und Respekt vor der Meinung anderer hochgehalten werden. Das alles fördert den Zusammenhalt im Team und somit auch den Erfolg des Softwareprojektes mit Scrum-Methodik.

Danksagung

Ich bedanke mich bei den Reviewern und Inspirationsgebern für diesen Blog Post: Mick Hohmann von Mayflower für seine wunderbare Metapher vom Labyrinth, sowie Irina, Tamas und Siegfried für Feedback zum Inhalt und Korrekturen. Dieser Blog Post ist auch in Englisch auf Medium abrufbar.