Der richtige Zeitpunkt für Planning Poker
Planning Poker ist eine Einschätzungsmethode, die auf Konsens beruht. Daher empfehle ich, es auch für Items zu nutzen, die Konsens erfordern – also eher für Product Backlog Items als für Tasks in einem Sprint Backlog. In diesem Beitrag gehe ich noch einmal auf Planning Poker ein und erkläre, wann man es durchführen sollte.
Gründe für das Einschätzen von User Stories
Das Einschätzen von User Stories in einem Product Backlog hat zwei Gründe:
1.) Der Product Backlog kann priorisiert werden. Stellen Sie sich zwei Product Backlog Items vor, die der Product Owner als gleichwertig erachtet. Das Item mit den niedrigsten Kosten wird dann zuerst in Angriff genommen. Die Bewertungen der Items hängen also von deren Kosten ab und können so für die Priorisierung genutzt werden.
2.) Das Unternehmen kann längerfristige Voraussagen treffen. Der Umfang der Arbeit muss bekannt sein, damit der Product Owner sagen kann, wann wie viel geliefert werden kann.
Wann sollte man Planning Poker spielen?
Mit Hilfe der oben genannten Punkte kann man herausfinden, wann ein Team Einschätzungen machen sollte. Es sollte einerseits so früh geschehen, dass diese beiden Voraussetzungen erfüllt werden können. Andererseits sollte es nicht früher als unbedingt notwendig geschehen.
In der Praxis gibt es zwei Situationen, in denen ein Team Planning Poker spielen sollte.
Ein guter Zeitpunkt für Planning Poker ist beispielsweise nach einem Story Writing Workshop, in dem viele Product Backlog Items erstellt wurden. Diese Workshops sollten etwa jedes Quartal durchgeführt werden.
So können der Product Owner und das Team ein größeres Ziel festlegen (das man nicht in einem einzelnen Sprint erreichen kann) und die dafür benötigten User Stories erstellen.
Typischerweise entstehen bei einem vierteljährlichen Story Writing Workshop 20 bis 50 Product Backlog Items. Wenn man etwa 20 Items pro Stunde einschätzen kann, braucht man für die Einschätzung insgesamt vielleicht zwei Stunden pro Quartal.
Des Weiteren kann Planning Poker auch einmal pro Sprint durchgeführt werden. Manche Teams machen das während des regulären Product Backlog Grooming Meetings. Das ist auch vollkommen in Ordnung – solange alle Teammitglieder daran beteiligt sind.
Wenn dabei nicht alle Teammitglieder involviert sind, kann man Planning Poker auch nach einem Daily Standup gegen Ende eines Sprints durchführen. Sollte ein Team zu früh während eines Sprints Einschätzungen machen, kann es sein, dass man alles noch einmal für Stories wiederholen muss, die später hinzugefügt werden.
Zu spät sollte die Einschätzung aber auch nicht erfolgen. Dann kann der Product Owner diese Items nämlich nicht bei der Festlegung der Items für den nächsten Sprint berücksichtigen.
Wann sollte man Planning Poker nicht spielen?
Es gibt einen Zeitpunkt, der ungünstig für Planning Poker ist: zu Beginn eines Sprint Planning Meetings. Dann ist es nämlich für den Product Owner zu spät, sich bei der Prioritätensetzung an den neuen Einschätzungen orientieren zu können.
Es gibt vielleicht Product Owner, die in kürzester Zeit die Prioritäten neu ordnen können. Mehr Zeit zu haben ist jedoch besser.
Ein weiteres Problem ist, dass ein Team fast immer zu viel Zeit mit Einschätzen verbringt, wenn ein Sprint Planning mit Planning Poker beginnt. Ich glaube das liegt daran, dass die Teammitglieder dann schon direkt über die Details ihrer User Stories nachdenken.
Beim Planning Poker sollten sie aber eigentlich eine weniger detaillierte Einschätzung ihrer User Stories abgeben. Es ist schwierig in einem Meeting eine so grobe Einschätzung abzugeben, wenn man die Tasks eigentlich viel genauer bewerten soll.
Das führt zu unnötig vielen Diskussionen. Und das wiederum führt dazu, dass das Team viel länger braucht, als wenn man beides separat durchführen würde.
Mit diesen Richtlinien sollten Sie in der Lage sein, den richtigen Zeitpunkt für Planning Poker zu finden.
Dieser Text stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.