Planning Poker hat sich in der Praxis durchgesetzt. Das Team hat so die Möglichkeit, in einem schnellen und effizienten Verfahren zu einer validen Schätzung zu gelangen. Üblicherweise werden Story Points geschätzt. Diese sind auch auf den entsprechenden Planning Poker Cards nach der Fibonacci-Folge dargestellt.

Story Points bilden nicht den Aufwand oder die Zeit ab, sondern die Komplexität einer Aufgabe. Eine hohe Zahl bedeutet hierbei eine hohe Komplexität und eine niedrige Zahl eine geringe Komplexität.

Die Komplexität wird über die Fibunacci-Reihe abgebildet:

Diese Reihe wird verwendet, denn je größer die Zahl, desto größer wird auch der Abstand zu Vorgänger und Nachfolger. Dadurch kann eine höhere Unsicherheit bei hohen Schätzungen abgebildet werden. Zusätzlich soll es zu schnelleren Entscheidungen kommen, da es zu keinen kleinteiligen Diskussionen kommt, wenn man eine einfache Zahlenfolge wählt. Die Schätzung hilft den Developers, zu überprüfen, ob nicht zu viele oder zu wenige Stories in den Sprint aufgenommen werden.

Planning Poker hat den folgenden Ablauf: Zunächst stellt der Serum Master das Vorgehen vor und übergibt in den meisten Fällen an den Product Owner für die inhaltlichen Themen. Dieser stellt dann die aktuellen Themen für das Meeting vor. Im Anschluss gehen Developers und Product Owner die einzelnen Backlog Items durch. Der Product Owner stellt die Beschreibung der Backlog Items vor, um ein gemeinsames Verständnis zu schaffen. Die Developers haben die Möglichkeit Rückfragen zu stellen. Nachdem ein gemeinsames Verständnis geschaffen worden ist, geht es in die erste Schätzrunde. Die Developers nehmen eine Schätzung für ein Backlog Item vor und legen die Karte mit der für sie passenden Zahl verdeckt auf den Tisch. Alle Developers drehen gemeinsam ihre Karten um, so dass die Schätzungen sichtbar werden. Die Developers mit den höchsten und niedrigsten Schätzungen begründen ihre Meinung. Dies soll eine große Diskussion vermeiden. Es folgt eine weitere Schätzrunde auf Basis der neuen Informationen für das gleiche Backlog Item. Dies Zyklus kann beliebig wiederholt werden, in der Regel maximal 3 Runden. Wenn es nach diesen drei Runden zu keiner Einigung gekommen ist, kann man eine Regel definieren, dass z.B. die Mehrheit der Schätzungen angenommen wird. Die Stimme des Developers, der die Aufgabe vermutlich umsetzen wird, sollte hierbei von den Developers respektiert werden. Falls es auch mit Regeln zu keiner Eignung kommt, sollte diese Schätzung vertagt und zum nächsten Backlog Item übergegangen werden.

Durch diese Schätzungen kann die Velocity (Geschwindigkeit) des SCRUM-Teams anhand der geschätzten Backlog Items gemessen werden. Bei gut performenden Teams steigt die Velocity im Laufe der Sprints immer mehr an. Es werden also mehr Story Points innerhalb eines Sprints umgesetzt. Diese Zahl ist auch für die Planung innerhalb des Product Backlog wichtig, da der Product Owner eine Möglichkeit bekommt, abzuschätzen, wie viel innerhalb eines Sprints umgesetzt werden kann.