<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=772457&amp;fmt=gif">

Kategorien: Softwareentwicklung


Planning Poker® ist eine beliebte Methode für das agile Schätzen von User Stories und Epics in Story Points in der agilen Softwareentwicklung. 

Typischerweise wird Planning Poker im Zuge eines Refinement Meetings gespielt.

Ziel ist es, zu einer User Story neues Wissen zu generieren sowie eine grobe Aufwandsschätzung zu erhalten.

Wie funktioniert Planning Poker

Diese Schätzmethode basiert auf der Breitband-Delphi-Methode, bei der mehrere Experten (in Scrum das Umsetzungsteam) zur Schätzung herangezogen werden und sich hinsichtlich ihrer Überlegungen untereinander abstimmen. Dadurch wird das Wissen dieser Experten konsolidiert, was  zu einem besseren Gesamtverständnis und somit auch zu besseren Schätzungen führt. 

Planning Poker Cards

Genauso wie das klassische Poker wird auch Planning Poker mit Karten gespielt. Jedem Mitglied des Umsetzungsteams werden folgende Karten ausgehändigt: 

  • Die modifzierte Fibonacci Sequenz
  • Fragezeichen - wenn jemand noch zu viele offen Fragen hat 
  • Kaffeetasse - wenn jemand eine Pause einlegen möchte
  • Unendlich - die gerade behandelte Story ist zu groß zum Schätzen



Planning Poker CardsPlanning Poker Cards: So sehen sie bei Objectbay aus. 

Wie läuft das Spiel ab? 

Beim allerersten Mal muss zunächst eine Referenz gefunden werden, da im relativen Schätzen ja die zu schätzenden Stories miteinander verglichen werden. 

Dazu muss einmalig ein vom Entwicklerteam gut greifbares, hinsichtlich Umfang und Komplexität überschaubares Backlog-Element als Referenz gewählt werden. Für dieses wird dann eine Größe festgelegt, die ebenfalls klein ist; in der Regel werden 2 Story Points gewählt, um noch etwas Raum für kleinere Elemente zu lassen.

Anmerkung: Diese 2 Story Points haben keinen direkten Bezug zur Dauer der Umsetzung, sondern dienen lediglich als Startwert, um weitere User Stories im Hinblick auf Ihre Größe mit dieser Referenz zu vergleichen. Wie lange das Team also brauchen würde, um diese Story umzusetzen, spielt zu diesem Zeitpunkt noch keine Rolle. 

Nun kann mit der ersten Runde Planning Poker begonnen werden. Dafür erhält jedes Teammitglied einen Stapel Planning Poker Cards. 

Für jedes zu schätzende Backlog-Element wird wie folgt vorgegangen:

  1. Der Product Owner stellt ein Backlog-Element vor und diskutiert es kurz mit dem Team,  um ein gemeinsames Verständnis hinsichtlich der Anforderungen zu gewinnen. Fragen sind dabei explizit erwünscht um sicherzugehen, dass die Aufgabenstellung richtig verstanden ist. Jedoch soll es hierbei um keine Umsetzungsdetails gehen, die für die Abschätzung nicht relevant sind.
  2. Jedes Teammitglied schätzt dieses Element im Vergleich zur Referenz bzw. den in der Vergangenheit geschätzten Elemente und wählt eine Karte, die diese Schätzung repräsentiert. Die Karte wird mit der Rückseite nach oben auf den Tisch gelegt, was signalisiert, dass die Schätzung erfolgt ist. Der Schätzwert bleibt jedoch, wie beim Pokern, geheim, um die anderen in ihrer Meinungsbildung nicht zu beeinflussen.
  3. Wenn alle Schätzer fertig sind, werden die Karten gleichzeitig umgedreht.


Welche Situation sind nun möglich? 

Nachdem die Schätzer ihre Karten aufgedeckt haben, können sich folgende Situationen ergeben:

  • Alle Schätzwerte sind gleich. Damit besteht Konsens und die User Story wird mit den entsprechenden Story Points versehen.
  • Die Schätzwerte unterscheiden sich voneinander. In diesem Fall werden die einzelnen Schätzungen den Kollegen erklärt, typischerweise beginnt man mit der höchsten sowie der niedrigsten Schätzung. Das bringt neues Wissen ins Team und hilft somit bei der nächsten Runde.
  • Nun wird wieder bei Schritt 2 weiter gemacht. Jeder Entwickler überlegt sich erneut, welche Schätzung für das Element mit dem neu gewonnenen Wissen am besten passt. Dies kann einige Male wiederholt werden, bis eine Einigkeit im Team herrscht. In der Diskussion ist die Berücksichtigung des relativen Vergleichs den Referenzen wichtig. Dem Scrum Master kommt hier eine wichtige Rolle als Moderator zu, der auch sicherstellen muss, dass sich alle Teammitglieder in die Diskussion einbringen können.
  • Falls es nicht gelingt, einen Konsens im Team herzustellen, wird die Schätzung der betreffenden User Story oder Epic auf einen weiteren Workshop verschoben. Bis dahin muss sie entweder in kleinere User Storys zerlegt oder fehlende Informationen recherchiert werden.


Planning Poker als Werkzeug für Wissensmanagement

Planning Poker ist ein hervorragendes Werkzeug für das Wissensmanagement, denn durch die Diskussion hinsichtlich der unterschiedlichen Einschätzungen im Team entstehen neue kollektive Erkenntnisse.

Der Ablauf, dass die Teammitglieder ihre Schätzungen so lange nicht bekannt geben, bis sich jeder eine Meinung gebildet hat, stellt sicher, dass jedes einzelne Teammitglied seine persönlichen Einschätzung abgibt und somit mitdenken muss.

Das gleichzeitige Umdrehen der Karten macht die Unterschiede im Wissen des Teams über die jeweilige User Story deutlich. Es werden die Unterschiede in der Einschätzung des einzelnen Teammitglieder transparent.

Durch die gemeinsame Diskussion der divergierenden Einschätzungen insbesondere der Extrema (niedrigster und höchster Wert) entstehen neue Erkenntnisse und somit Wissen, das in einer weiteren Schätzrunde als Basis dient. Erfahrungsgemäß entsteht nach zwei bis drei Runden kein neues Wissen mehr.

PLANNING POKER® ist eine eingetragene Marke des Unternehmens Mountain Goat Software.

Sie wollen mehr über die Arbeitsweise bei Objectbay erfahren?

Hier geht's zum Whitepaper „So läufts @Objectbay."

JETZT HERUNTERLADEN!

 

Für E-Mail-Updates anmelden!

Abonnieren Sie jetzt den Objectbay Blog und erhalten Sie monatlich die besten Beiträge rund um agile Softwareentwicklung.

Für E-Mail-Updates anmelden

Suchen