Agile Techniken – Planning Poker

Was ist das?

Planning Poker ist eine Methode zur Einschätzung von Themen in einer Gruppe.

Wozu kann ich das verwenden?

Zunächst verwenden Scrum Teams das Planning Poker zur Bewertung der Stories aus dem Backlog. Dies geschieht meist während des Sprint Planning Meetings. Der Product Owner kann das Team auch an anderen, geplanten Terminen bitten, die Stories zu bewerten. Dadurch kann er anhand der Story Points und der durchschnittlichen Velocity abschätzen, wie viele Sprints bzw. die Umsetzung des gesamten Backlogs dauern würde.

Oft ruft der Product Owner das Team vor dem Sprint Planning zusammen, um die Stories für den nächsten Sprint zu bewerten – das hilft ihm vor allem, frühzeitig Unklarheiten und implizite Annahmen aufzudecken, die sonst erst im Sprint erkannt werden. Ein guter Product Owner zerlegt komplexe Stories in weniger komplexe, um die Risiken zu minimieren.

Man kann Planning Poker auch für die Priorisierung von Themen nutzen, z.B. in einem Meeting mit zu kleinem Zeitfenster: dann legt das schnelle Bewerten eine gemeinsame Reihenfolge fest. Gleichzeitig werden unterschiedliche Bewertungen im Team deutlich. Die Priorität ist dabei nach oben offen – damit nicht wieder „Priorität 0“ eingeführt werden muss.

                                    

Worauf muss ich achten?

Der Ablauf ist:

1. Der Product Owner stellt die Story aus dem Backlog vor.
2.  Das Team stellt Verständnisfragen zur Klärung – Diskussionen finden dabei nicht statt.
3. Alle Teammitglieder zeigen gleichzeitig ihre Schätzungen. Sie schätzen dabei die Komplexität – nicht den Aufwand: 1000 Blätter zu falten ist aufwändig, aber nicht komplex. Aus einem Blatt einen Papierflieger zu falten, der 10 Meter weit fliegen kann, kann ziemlich komplex sein.
4. Falls sich unterschiedliche Einschätzungen ergeben: Die Teammitglieder mit der höchsten und niedrigsten Schätzung diskutieren ihre Annahmen – alle anderen schweigen.
5. Falls zu viele Fragezeichen oder sehr unterschiedliche Bewertungen gezogen  werden, kann das Team die Überarbeitung der Story durch den Product Owner verlangen.
6. Falls Fragen geklärt wurden, wird die Pokerrunde wiederholt.
7. Bei Einigkeit vermerkt der Product Owner die Story Points zur Story.
8. Der Scrum Master achtet auf eine zügige Abwicklung.

Das Team muss dafür sorgen, dass auch Teammitglieder schätzen können, die das Thema vorher nicht oder nur ansatzweise kennen – insbesondere sind keine Expertenschätzungen gewünscht, weil die Experten womöglich gar nicht zur Verfügung stehen. Eine Vorherrschaft von einzelnen Experten steht auch der Bildung eines leistungsfähigen Teams entgegen.

In den Diskussionen zu höchster und niedrigster Schätzung geht es nicht um Meinungen, sondern um Risiken, Grundannahmen, unterschiedliche Vorstellungen über den Umfang der Arbeiten, ...

Das Team kann zu neuen Einschätzungen gelangen, etwa, dass der Product Owner die Story zurücknehmen und überarbeiten muss.

Oft hilft es bei komplizierten Sachverhalten, die Kernaussagen und Argumente zu verdichten auf das Niveau der „Schlagzeilen einer Boulevard-Zeitung“ – prägnante Begriffe und Sätze helfen, die unterschiedlichen Varianten abzugrenzen, auch wenn sich hinter ihnen viele Details verbergen.

Ein effizientes Planning Poker erfordert eine disziplinierte Diskussionskultur in der Gruppe.

Beispiele

Der Product Owner lässt das Team Planning Poker für Stories aus dem Backlog durchführen, damit er anhand der Bewertung die Verteilung der Stories auf die nächsten Sprints planen kann – und damit z.B. dem Kunden die mögliche Gesamtdauer ankündigen kann.

Das Team ist frustriert, weil zu viele Themen in einer Besprechung zu diskutieren sind. Andererseits kann es sich auch nicht auf eine Priorisierung einigen. Der Scrum Master lässt das Team per Planning Poker die Prioritäten festlegen. In der folgenden Timebox werden dann die Themen nach absteigender Priorität bearbeitet.