Agile Schätzen (Planning Poker)

I. Fundament & Systematik

Wer den Chef oder den Senior-Experten zuerst schätzen lässt, hat das Planungsergebnis bereits ruiniert. Planning Poker vernichtet den psychologischen Anker-Effekt durch eiskalte, verdeckte Abgabe der Werte. Es verwandelt vage Bauchgefühle in einen harten, kalibrierten Teamkonsens und deckt radikal auf, wenn zwei Entwickler völlig unterschiedliche technische Vorstellungen von ein und derselben Aufgabe haben.

Steckbrief & Key Facts

Kategorie

Projektmanagement- & Aufwandsschätzungsmethode

Schweregrad | Komplexität

Niedrig (Die Mechanik ist trivial, die Disziplin zur Vermeidung endloser technischer Detaildiskussionen erfordert jedoch harte Moderation)

Investition | Ressourcen

Sehr gering (Ein Kartenset mit Fibonacci-Zahlen pro Teilnehmer oder eine kostenlose digitale Web-App)

Empfohlene Gruppengröße

3 bis 9 Personen (Entwicklungsteam, Scrum Master, Product Owner)

Zeitaufwand

60 bis 120 Minuten (Typischerweise im Sprint Planning oder Backlog Refinement)

Einsatzbereiche

Agile Softwareentwicklung, Sprint Planning, Anforderungsanalyse, Komplexitätsbewertung

Brancheneinsatz

Ursprünglich aus der agilen Softwareentwicklung, heute branchenübergreifend im Systems Engineering, in der Hardware-Entwicklung und im strategischen Projektmanagement etabliert.

Inhalt

I. Fundament und Systematik
II. Methodik und Anwendung
III. Evaluation und Risikomanagement
IV. Praxis und Mehrwert
V. Verzeichnisse und Anhang

🎯 Ziele und Grundidee

Das absolute Primärziel des Planning Pokers in der agilen Produktentwicklung ist die Kalibrierung des gemeinsamen Systemverständnisses durch relative Aufwandsschätzung. Wenn ein klassischer Projektleiter fragt, wie viele Stunden ein Feature benötigt, erhält er meist eine politisch motivierte Lüge mit eingebautem Sicherheitspuffer. Planning Poker bricht dieses toxische Muster auf. Es schätzt keine absoluten Stunden, sondern relative Komplexität, den sogenannten Story Point. Das Team vergleicht die neue Aufgabe eiskalt mit einer bereits bekannten Basis-Aufgabe. Durch den Zwang, sich auf eine fest vorgegebene Fibonacci-Zahl festzulegen, werden Scheingenauigkeiten vernichtet und der Fokus auf das echte physikalische oder logische Risiko des Arbeitspaketes gelenkt.

Methodisch unterscheidet sich Planning Poker fundamental von der klassischen Expertenbefragung (Delphi-Methode) oder dem simplen T-Shirt-Sizing. Decken zwei Entwickler völlig extreme Werte auf, etwa eine kleine Zwei und eine massive Zwanzig, offenbart dies keinen simplen Fehler im Schätzvermögen, sondern ein eklatantes Missverständnis in den formulierten Anforderungen. Die Methode zwingt exakt diese beiden Extreme sofort in den harten Dialog. Derjenige mit der Zwanzig hat fast immer ein verstecktes Systemrisiko oder eine Integrationshürde erkannt, das der Rest des Teams blind übersehen hat. Somit ist Planning Poker weniger ein reines Schätzwerkzeug, sondern primär ein gnadenloses Analyseinstrument für Requirements.

II. Methodik und Anwendung

Methode im Detail

🔍

📌 Grundregeln und Anwendungsprämissen

Die Verdeckt-Prämisse

Keine Schätzung darf laut ausgesprochen oder vorab gezeigt werden. Alle Teilnehmer wählen ihre Karte stumm und verdeckt aus und decken sie auf ein exaktes Kommando zeitgleich auf. Dies ist die absolute Grundvoraussetzung, um den Anker-Effekt des ersten Sprechers eiskalt zu vernichten und das echte Wissen zu extrahieren.

Die Fibonacci-Maxime

Es wird zwingend eine modifizierte Fibonacci-Folge genutzt, meist 0, 1, 2, 3, 5, 8, 13, 20, 40 und 100. Je größer die Unsicherheit des Pakets, desto größer der mathematische Abstand zwischen den Zahlen. Es gibt keine Karte für die Zahl 21 oder 22. Diese künstliche Spreizung zwingt das Team dazu, falsche Präzision aufzugeben.

Das Rechtfertigungs-Gebot

Nach dem Aufdecken müssen sich ausschließlich die extremen Ausreißer nach oben und nach unten erklären. Wer mit dem Mainstream der Gruppe schätzt, schweigt. Der Fokus liegt eiskalt auf dem Erkenntnisgewinn der Abweichler, da diese entweder eine geniale Abkürzung kennen oder ein massives Risiko entdeckt haben.

Das Schätzverbot für den Anforderer

Der Product Owner oder Kunde stellt die Aufgabe vor und beantwortet fachliche Fragen, darf aber unter keinen Umständen selbst mitschätzen. Wer die Arbeit nicht physisch ausführt, hat bei der technischen Aufwandsbewertung absolutes Hausverbot, um jeglichen politischen Budgetdruck auf das Umsetzungsteam zu verhindern.

🧰 Erforderliches Kompetenzlevel und Ausstattung

Eiskalte Moderationskompetenz, typischerweise durch den Scrum Master ausgeführt, um ausufernde architektonische Lösungsdiskussionen sofort abzubrechen und das Team zwingend auf die reine Aufwandsschätzung und Risikobetrachtung zurückzuführen.

Ein tiefes methodisches Verständnis der relativen Schätzlogik im gesamten Team, da Entwickler, die versuchen, Story Points im Kopf heimlich wieder in harte Stunden umzurechnen, die gesamte Systematik der Methode sofort vernichten.

Physische Planning Poker Kartendecks für jeden Teilnehmer im Raum oder der Zugang zu einer dedizierten, latenzfreien Online-Schätz-Software für hybrid arbeitende Teams.

🧱 Detaillierte Aufschlüsselung der Kernkomponenten

Rolle 1 Der Product Owner

Fokus auf den Kundennutzen. Denkweise ist anforderungsgetrieben und klärend. Ziel ist die unmissverständliche Vermittlung des Nutzens der User Story. Typische Fragestellung lautet: Welche geschäftskritischen Randbedingungen müssen wir zwingend erfüllen, damit diese Funktion für den Endanwender überhaupt einen Wert generiert?

Rolle 2 Das Entwicklungsteam

Fokus auf die Umsetzung. Denkweise ist extrem technisch, aufwandsorientiert und risikoscheu. Ziel ist die relative Einordnung der Komplexität im direkten Vergleich zu bekannten Referenzaufgaben. Typische Fragestellung lautet: Ist die Integration dieser neuen Datenbank wirklich doppelt so komplex wie die simple Anbindung aus dem letzten Sprint?

Rolle 3 Der Scrum Master

Fokus auf den methodischen Prozess. Denkweise ist disziplinierend und moderierend. Ziel ist die strikte Einhaltung der Poker-Regeln und die Verhinderung toxischer Gruppendynamiken. Typische Fragestellung lautet: Sind nun alle Fragen zur Anforderung glasklar beantwortet, sodass wir jetzt stumm und verdeckt unsere Karten wählen können?

🌐 Online-Durchführbarkeit

Die Methodik ist vollständig und ohne jeglichen Qualitätsverlust digitalisierbar. Der empfohlene Einsatz von Cloud-basierten Schätz-Tools integriert sich heute nahtlos in das Backlog-Management. Diese Tools erzwingen das verdeckte Schätzen systemseitig und berechnen nach dem Aufdecken automatisch Durchschnittswerte und Ausreißer, was die Dokumentationsarbeit auf ein absolutes Minimum reduziert.

Anwendung

🔨

Definition der Basis-Story (Baseline)

Bevor das erste Mal gepokert wird, zwingt der Moderator das Team, ein Referenz-Arbeitspaket auszuwählen. Dies muss eine kleine, völlig verstandene und bereits abgeschlossene User Story sein. Diese Basis-Story erhält fix den Wert zwei oder drei. Jedes zukünftige Arbeitspaket wird ab sofort eiskalt in Relation zu dieser Basis gesetzt. Ohne diesen mentalen Kalibrierungsschritt hängt die gesamte Schätzung später völlig frei im Raum und wird wertlos.

Präsentation des Arbeitspaketes

Der Product Owner liest die zu schätzende Anforderung laut vor und erklärt die exakten Akzeptanzkriterien. Er definiert glasklar, welcher Zustand in der Software oder Hardware erreicht sein muss, damit die Aufgabe formell als erledigt gilt. Das Entwicklerteam hört in dieser Phase ausschließlich zu und verarbeitet die geschäftlichen Anforderungen ohne sofort zu bewerten.

Klärung von Unschärfen (Q&A-Phase)

Das Entwicklungsteam löchert den Product Owner mit eiskalten Rückfragen. Fehlen Design-Vorgaben? Gibt es externe Abhängigkeiten zu anderen Abteilungen? Der Scrum Master überwacht diese Phase pedantisch. Sobald ein Entwickler beginnt, am Whiteboard die technische Lösung zu konstruieren, anstatt das Was zu klären, bricht der Moderator die Diskussion unbarmherzig ab.

Die verdeckte Schätzabgabe

Sobald alle fachlichen Fragen geklärt sind, fordert der Moderator das Team zur Schätzung auf. Jeder Schätzer wählt stumm seine Karte aus dem Fibonacci-Deck. In dieser Sekundenbruchteil-Phase darf nicht mehr gesprochen, genickt oder geseufzt werden. Die Karte wird verdeckt auf den Tisch gelegt oder im digitalen Tool unsichtbar für die Kollegen eingeloggt.

Das simultane Aufdecken

Auf ein klares Kommando des Moderators decken alle Teilnehmer ihre Karten im exakt selben Bruchteil einer Sekunde auf. Diese absolute Gleichzeitigkeit ist der psychologische Kern der Methode, da sie den gefährlichen Ankereffekt des Senior-Entwicklers gnadenlos vernichtet und das reine, unbeeinflusste Wissen und Bauchgefühl jedes einzelnen Teilnehmers schonungslos offenlegt.

Analyse der Ausreißer

Der Moderator ignoriert die Mitte der Schätzungen und fokussiert sich sofort auf die absoluten Ränder. Haben vier Entwickler eine Fünf geschätzt, aber einer eine Dreizehn und einer eine kleine Eins, erhalten exakt diese beiden das Wort. Der Moderator fragt den Höchstbietenden eiskalt, welches versteckte Risiko er sieht, das der Rest des Raumes offenbar völlig ignoriert hat.

Die technische Kurz-Diskussion

Der Teilnehmer mit der extrem hohen Schätzung argumentiert sein Risiko, beispielsweise eine übersehene Legacy-Code-Schnittstelle. Der Teilnehmer mit der extrem niedrigen Schätzung argumentiert seinen optimistischen Ansatz, etwa eine bereits fertige Bibliothek, die nur importiert werden muss. Das restliche Team passt sein geistiges Modell basierend auf diesen neuen, harten Fakten an.

Die zweite Schätzrunde

Nach der kurzen, klärenden Konfrontation ordnet der Moderator zwingend eine erneute verdeckte Schätzrunde an. Das Team wählt basierend auf den neuen Erkenntnissen erneut stumm eine Karte. In fast allen Fällen rücken die Schätzungen nun massiv zusammen, da das Wissensdefizit in der Gruppe durch die offene Diskussion der Extreme erfolgreich nivelliert wurde.

Konsensfindung und Fixierung

Liegen die Werte in der zweiten Runde sehr nah beieinander, beispielsweise bei reinen Vieren und Fünfen, diktiert der Moderator den Konsenswert. Bei kleinen Abweichungen wird im Zweifel immer auf die nächsthöhere Fibonacci-Zahl aufgerundet, um nicht messbare Systemrisiken abzufedern. Dieser Wert wird als feste Punktzahl in das Ticket eingetragen.

Re-Fokussierung oder harter Abbruch

Können sich die Teilnehmer auch nach drei zähen Poker-Runden absolut nicht einigen und schätzen weiterhin extrem weit auseinander, bricht der Moderator das Pokern für dieses Ticket eiskalt ab. Das Arbeitspaket wandert sofort zurück zum Product Owner. Es ist der ultimative Beweis, dass die Anforderungen noch viel zu diffus sind, um sie in den nächsten Sprint aufzunehmen.

Ergebnis

📦

Operatives Ergebnis

Ein quantitativ kalibriertes Backlog, bei dem jede User Story mit einem verbindlichen, vom gesamten Team getragenen Story-Point-Wert versehen ist.

Teambezogenes Ergebnis

Ein massiv vertieftes, gemeinsames Architekturverständnis, da Randbedingungen und technische Risiken durch die Diskussion der Ausreißer gnadenlos offengelegt wurden.

Dokumentatorisches Ergebnis

Die harte numerische Basis für die Berechnung der Team-Velocity, mit der das Management datengetrieben die Reichweite der kommenden Sprints prognostizieren kann.

Alternativen

🧩

III. Evaluation und Risikomanagement

Tipps

💡

Aus der Praxis für die Praxis

Wertvolle Expertenhinweise helfen dir dabei, typische Stolpersteine zu umgehen, die Effizienz bei der Umsetzung drastisch zu steigern und das volle Potenzial der Methode direkt im operativen Alltag auszuschöpfen

Tipp 1: Nutzen Sie die Fragezeichen-Karte konsequent. Wenn ein Entwickler absolut keine Idee hat, wie ein Feature technisch funktioniert, muss er das Fragezeichen spielen. Das zwingt den Product Owner, die Story komplett neu zu erklären, anstatt dass der Entwickler blind rät und die Kalkulation ruiniert.

Tipp 2: Trennen Sie relativen Aufwand strikt von absoluter Zeit. Verhindern Sie mit eiserner Härte, dass Entwickler anfangen zu rechnen, dass ein Story Point exakt einem Arbeitstag entspricht. Wer das zulässt, vernichtet den gesamten Nutzen der relativen Schätzung.

Tipp 3: Pokern Sie niemals zu große Tickets. Wenn das Team regelmäßig vierzig oder hundert Story Points zieht, ist das Ticket viel zu fett. Zwingen Sie den Product Owner, solche komplexen Epics sofort in kleine, schätzbare Happen zu zerschneiden, bevor Sie weiter diskutieren.

Fallstricke

⚡

Wo Licht ist, ist auch Schatten

In der Praxis führen typische Fehler oft dazu, dass die Anwendung der Methode ihr volles Potenzial verfehlt.

Stärken und Grenzen

⚖️

Jede Methode hat ihren optimalen Einsatzbereich

Die Anwendung bietet enorme strategische Vorteile, stößt bei unvollständiger Ausführung jedoch an klare Grenzen.

Wann bringt die Methode besonderen Nutzen?

+ Zerschlägt den psychologischen Ankereffekt und erzwingt, dass wirklich das kollektive Schwarmwissen des gesamten Teams in die Aufwandsbewertung einfließt.
+ Deckt durch die geforderte Diskussion der extremen Schätzabweichungen gnadenlos und präventiv auf, wenn Requirements vom Team massiv missverstanden wurden.
+ Generiert eine extrem hohe Akzeptanz für Commitments, da das Team den Aufwand selbst geschätzt hat und keine fertigen Zeiten von oben durch das Management diktiert wurden.
+
+

Was sind die Grenzen der Methode?

∼ Die Methode ist völlig nutzlos, wenn das Team in einer klassischen Wasserfall-Struktur arbeitet, in der am Ende das Management die Story Points doch wieder per Excel in fakturierte Personenstunden umrechnet.
∼ Erzeugt bei extrem unvorbereiteten Product Owners einen massiven Zeitverlust, da jedes Ticket in endlose Erklärungs-Schleifen ausartet und das Schätz-Meeting blockiert.
∼ Skaliert sehr schlecht bei hochgradig inkompatiblen Spezialisten. Wenn nur ein Datenbank-Experte im Raum sitzt, macht es keinen Sinn, dass drei Frontend-Designer sein Ticket blind mitpokern.
∼
∼

Erfolgsmetriken (KPIs)

📐

Estimation Convergence Rate

Die absolute Anzahl der Runden, die das Team benötigt, um bei einer User Story einen Konsens zu finden. Sinkt dieser Wert über die Sprints, beweist dies eine drastische Verbesserung der Requirement-Qualität.

Sprint Velocity Stability

Die prozentuale Abweichung der abgelieferten Story Points von Sprint zu Sprint. Planning Poker führt mittelfristig zu einer eiskalt kalkulierbaren, stabilen Velocity ohne massive Schwankungen.

IV. Praxis und Mehrwert

⚙️ Praxisrelevanz in unserem professionellen Ingenieursumfeld

Wir wenden diese Methode fast täglich an, um komplexe Herausforderungen zu strukturieren und messbare Resultate für unsere Kunden zu erzielen. Die folgenden drei Praxisfälle veranschaulichen, wie sich dieser Ansatz erfolgreich realisieren lässt:

Qualitätsmanagement

Im Qualitätsmanagement dient die Methode zur ehrlichen Aufwandsbewertung von Korrekturmaßnahmen. Wenn die Abarbeitung eines 8D-Reports geschätzt wird, verhindert das Pokern, dass kritische Qualitätsprobleme durch zu optimistische Managementschätzungen unter die Räder kommen.

Systems Engineering

Im Systems Engineering wird das Format genutzt, um interdisziplinäre Komplexität zu bewerten. Wenn Hardware- und Software-Ingenieure verdeckt pokern, deckt die Methode gnadenlos auf, wenn die Mechanik ein massives Integrationsrisiko in der Software-Schnittstelle übersehen hat.

Risikomanagement

Im Risikomanagement kann die modifizierte Fibonacci-Folge genutzt werden, um Eintrittswahrscheinlichkeiten jenseits starrer Excel-Matrizen im Expertenteam verdeckt zu schätzen, um den menschlichen Bestätigungsfehler bei der Risikobewertung auszuschalten.

🏢 Fallbeispiele aus der Praxis

Theorie wird erst durch messbaren Nutzen im Feld zur Validität: Die folgenden anonymisierten Praxisfälle aus unserer QM- und Systems-Engineering-Beratung dokumentieren den konkreten Methodeneinsatz, die durchgeführten Ursachenanalysen und die quantifizierbaren Projekterfolge unter realen Industriebedingungen.

Fallbeispiel 1: Softwareentwicklung - Der unsichtbare Datenbank-Trigger

Problem: Eine vermeintlich simple Ticket-Anforderung verlangte das Hinzufügen eines Textfeldes in der Benutzeroberfläche. Der Product Owner schätzte intern auf eine minimale Dauer. Methodeneinsatz: Beim Planning Poker zogen drei Front-End-Entwickler eine winzige Zwei, aber der Datenbank-Spezialist zog eiskalt eine gigantische Vierzig. Ergebnis: Die Diskussion der Ausreißer legte offen, dass das neue Feld einen kritischen Legacy-Trigger im Backend auslöst, der das gesamte ERP-System lahmlegen könnte. Die Story wurde umstrukturiert, was einen katastrophalen Serverausfall beim Rollout verhinderte.

Fallbeispiel 2: Maschinenbau - Das ignorierte Frästeil

Problem: Ein agiles Mechatronik-Team verschätzte sich chronisch bei der Dauer von Prototypen-Iterationen, da der Lead-Ingenieur die Bearbeitungsdauern stets extrem optimistisch diktierte. Methodeneinsatz: Die Einführung von Planning Poker unter Zwang beendete das Diktat. Niemand durfte vor dem Aufdecken sprechen. Ergebnis: Der Junior-Fertiger zog konsequent hohe Karten, weil er wusste, dass die Rüstzeiten an der Fräse bei dieser Geometrie dreimal so lange dauerten wie vom Lead-Ingenieur berechnet. Die Deadlines wurden korrigiert und ab diesem Zeitpunkt fehlerfrei eingehalten.

Fallbeispiel 3: Medizintechnik - Die blockierte Validierung

Problem: Ein Firmware-Update für ein Ultraschallgerät lag dauerhaft hinter dem Zeitplan, da die reine Coding-Zeit korrekt, die behördliche Validierungs-Zeit jedoch völlig falsch geschätzt wurde. Methodeneinsatz: Das Team wurde gezwungen, die Definition of Done vor dem Pokern penibel zu lesen. Ergebnis: Ein Tester zog die Karte Hundert, da das Update eine vollständige Neu-Zertifizierung der FDA-Modultests erzwingen würde. Durch diese extreme, verdeckte Schätzung wurde das Feature sofort aus dem aktuellen Sprint entfernt und als eigenständiges Compliance-Projekt geplant.

💬 Expertenzitate

Einschlägige Fachzitate zur wissenschaftlichen und normativen Einordnung der Methode.

♦ Mike Cohn (2005): 'Es ist viel wichtiger, dass das Team bei der Schätzung denselben Irrtum teilt und darüber spricht, als dass ein einzelner Experte aus Versehen die exakt richtige Stundenzahl rät.'

♦ James Grenning (2002): 'Wenn Schätz-Meetings so quälend sind, dass Entwickler lieber programmieren würden, anstatt zu planen, dann ist der Prozess kaputt. Planning Poker macht aus dem Verhör ein kollaboratives Spiel.'

♦ 

V. Verzeichnisse & Anhang

📇 Glossar

ERP = Enterprise Resource Planning | FDA = Food and Drug Administration | Q&A = Questions and Answers

📰 Blogbeiträge zu Agile Schätzen (Planning Poker)

Vertiefe dein Wissen: Hier findest du aktuelle Fachartikel, fundierte Hintergrundberichte und weiterführende Analysen aus unserem Redaktionsnetzwerk, die sich praxisnah mit der Anwendung und den Feinheiten dieser Methode auseinandersetzen.

🎬 Videobeitrag zu Agile Schätzen (Planning Poker)

In klassischen Projektplanungen dominiert oft der Ankereffekt: Die erste Person, die eine Schätzung abgibt, meist der erfahrenste Experte, beeinflusst den Rest des Raumes massiv. Die hier vorgestellte agile Schätzmethode zerstört diese gefährliche Dynamik radikal. Sie nutzt verdeckte, gleichzeitige Kartenabgaben basierend auf einer relativen Größenskala, meist der Fibonacci-Folge. Teilnehmer bewerten Arbeitspakete nicht in absoluten Stunden, sondern in relativer Komplexität. Der Kernnutzen liegt nicht im errechneten Durchschnitt, sondern in der Diskussion der Extreme. Wenn Schätzungen extrem weit auseinanderklaffen, erzwingt der Moderator einen fachlichen Dialog. Dies deckt Missverständnisse in den Anforderungen frühzeitig auf, nivelliert das kollektive Systemverständnis und verwandelt Bauchgefühle in einen unbestechlichen, datengetriebenen Teamkonsens.

🎙️ Audiotranskript zu Agile Schätzen (Planning Poker)

Willkommen zur kompakten Methoden-Übersicht. Diktieren in Ihren Planungsmeetings die lautesten Experten die Dauer von Aufgaben? Beenden Sie dieses Ratespiel. Nutzen Sie Planning Poker. Zwingen Sie Ihr Team, Aufwände stumm und verdeckt zu schätzen. Verknüpfen Sie die Schätzung an eine Fibonacci-Skala, um Scheingenauigkeiten bei komplexen Aufgaben zu vernichten. Alle decken zeitgleich auf. Der Ankereffekt ist Geschichte. Betrachten Sie eiskalt die Ausreißer. Warum schätzt einer extrem hoch und einer extrem niedrig? Diskutieren Sie genau hier. Wer hoch schätzt, sieht meist ein technisches Risiko, das alle anderen blind übersehen haben. Pokern Sie erneut, bis der Konsens steht. Transformieren Sie unklare Lastenhefte durch diesen gnadenlosen Dialog in kalibrierte Arbeitspakete, denen Ihr gesamtes Team vertraut.