Planning Poker ist eine auf Konsens basierende Technik zur Abschätzung von Product Backlog Einträgen oder anderen Dingen in Scrum. Üblicherweise schätzen Teams die relative Größe der Einträge. Planning Poker führt zu verlässlichen und effizienten Schätzungen, weil das Team ein gemeinsames Verständnis über die zu schätzenden Einträge erlangt. Planning Poker ist eine Variante der Wideband Delphi-Methode.

Beim Planning Poker werden ein Planning Poker- Kartenset für jeden Teilnehmer und eine Liste mit zu schätzenden Größen (wie zum Beispiel User Stories) benötigt. Das Entwicklungsteam schätzt die Einträge im Product Backlog. Der Product Owner stellt die Einträge vor. Der Scrum Master moderiert den Prozess.

Es hat sich bewährt, den Umsetzungsaufwand der Einträge relativ zueinander zu schätzen, weil diese Größen unabhängig von individuellen Einflussfaktoren wie z. B. Entwicklungsfähigkeiten einer Person sind.

Für die relative Schätzung wird ein „kleiner“ Referenzeintrag festgelegt, der die Größe 1 bekommt („Urmeter“). Diese Einheit nennt man häufig „Story Point“. Alle anderen Einträge werden relativ dazu geschätzt (zum Beispiel: „Eintrag XYZ ist doppelt so aufwändig umzusetzen wie der Referenzeintrag“).

Zur Schätzung der weiteren Einträge geht das Entwicklungsteam wie folgt vor: Der Product
Owner stellt jeweils einen Eintrag aus dem Product Backlog im Detail vor und beantwortet alle wichtigen Verständnisfragen. Dann schätzt jedes Teammitglied, wie viel Aufwand der vorgestellte Eintrag im Vergleich zum Referenzeintrag hat. Dazu wählt jeder für sich verdeckt die Karte mit dem entsprechenden Schätzwert. Wenn alle ihren Schätzwert gewählt haben, werden die Karten gleichzeitig umgedreht.

Liegt kein Konsens vor, d. h. wenn nicht alle den selben Kartenwert gewählt haben, erklären die beiden Teammitglieder, deren Schätzwerte am weitesten auseinander liegen, warum sie den jeweiligen Wert gewählt haben. Das Team diskutiert darüber und
es folgt eine weitere Schätzrunde. Kann sich das Team nicht auf einen Wert einigen, ist das häufig ein Indikator dafür, dass die User Story unklar formuliert ist. Dann kann sich das Team beispielsweise auf den höchsten Schätzwert einigen oder entscheiden, die User Story aus der Schätzrunde zu nehmen und zu präzisieren.