Planning Poker

Der Planning Poker-Begriff bezeichnet eine spielerische Methode zur konsensbasierten Schätzung von Arbeitseffort in agilen Projekten, insbesondere im Scrum-Rahmenwerk. Teilnehmer nutzen Karten mit Zahlenwerten, um unabhängig zu schätzen und anschließend zu diskutieren, um Konsens zu erreichen. Dies unterstützt die Verwendung von Story Points und lässt sich auf andere Schätzungen anwenden.

Kurzüberblick

Planning Poker ist eine Technik zur Schätzung von Aufgaben in agilen Projekten. Sie fördert unabhängige Meinungen, reduziert kognitive Verzerrungen wie Anchoring Bias und stärkt den Teamkonsens durch strukturierte Diskussionen. Die Methode nutzt Spielkarten, um Schätzungen zu verdecken und gleichzeitig aufzudecken, was Effizienz und Wissensaustausch ermöglicht.

Kontext und Einordnung

Planning Poker entstand 2002 durch James Grenning und wurde 2005 durch Mike Cohn populär. Es ist eine Variante der Wideband Delphi-Methode aus den 1970er Jahren, angepasst für agile Teams. Obwohl nicht formal Teil des Scrum Guides, wird es häufig in Scrum-Events wie Sprint Planning und Backlog Refinement verwendet. Es unterstützt agile Prinzipien wie Zusammenarbeit und Reaktion auf Veränderungen.

Begriffe und Definitionen

• Story Points: Relative Einheit zur Messung des Arbeitsefforts, oft in Planning Poker verwendet.
• Konsensbasierte Schätzung: Das Team arbeitet zusammen, um eine gemeinsame Schätzung zu erreichen.
• Anchoring Bias: Kognitive Verzerrung, bei der die erste genannte Zahl nachfolgende Schätzungen beeinflusst; Planning Poker vermeidet dies durch verdeckte Karten.
• Modifizierte Fibonacci-Folge: Zahlenreihe (0, 1, 2, 3, 5, 8, 13, 20, 40, 100), die Unsicherheit bei höheren Werten berücksichtigt.
• Wideband Delphi: Ursprüngliche Schätzungsmethode, auf der Planning Poker basiert.

Vorgehen

Der Ablauf von Planning Poker folgt einem strukturierten Prozess, geleitet von einem Moderator, und eignet sich für die Ablauforganisation von Schätzungstätigkeiten:

1. Der Moderator führt die Methode ein und erläutert das zu schätzende Element, z. B. eine User Story.
2. Der Product Owner präsentiert das Element und beantwortet Fragen zu Annahmen und Risiken.
3. Die Teilnehmer diskutieren das Element, ohne Schätzungen laut zu nennen.
4. Jeder Teilnehmer wählt privat eine Karte und legt sie verdeckt auf den Tisch.
5. Alle decken ihre Karten gleichzeitig auf.
6. Die Personen mit den höchsten und niedrigsten Schätzungen begründen ihre Einschätzungen.
7. Nach der Diskussion erfolgt eine erneute Schätzrunde.
8. Die Schritte 5 bis 7 wiederholen sich, bis Konsens erreicht ist oder das Element verschoben wird.

Der Moderator achtet auf Zeitlimits und stellt sicher, dass alle Stimmen gehört werden.

Beispiele

Ein Team schätzt die User Story "Als Benutzer möchte ich mich mit E-Mail und Passwort einloggen". Nach Präsentation und Diskussion (Risiken: Sicherheit, Validierung) legen die Teilnehmer Karten auf: 5, 5, 8, 8, 13. Die Person mit 13 erklärt Bedenken zu Integration mit externen Diensten. Nach Diskussion einigen sich alle auf 8 Story Points.

Häufige Fehler und Tipps

• Künstlicher Konsens sollte vermieden werden; er sollte natürlich entstehen.
• Schätzungen nicht vor der Kartenauswahl erwähnen, um Anchoring zu vermeiden.
• Nicht zu schnell vorgehen; Diskussionen fördern Wissensaustausch.
• Alle Disziplinen einbeziehen für cross-funktionale Perspektiven.
• Schätzungen nicht als feste Zusagen behandeln; sie sind relativ.

Empfehlungen: Eine Baseline-Story für Vergleiche etablieren, Zeitlimits nutzen und "? "-Karten für Unsicherheit zulassen.

Weiterführendes

Planning Poker lässt sich mit Tools für verteilte Teams anwenden und ergänzt Techniken wie Velocity-Tracking.