Planning Poker: Der vollständige Leitfaden zur agilen Schätzung für Scrum Teams

Planning Poker ist eine konsensbasierte Schätzungstechnik, bei der jedes Mitglied des Scrum Teams privat eine Karte auswählt, die seine Schätzung darstellt, und dann alle Karten gleichzeitig aufgedeckt werden, um Verzerrungen zu vermeiden. Erfunden von James Grenning im Jahr 2002 und später von Mike Cohn populär gemacht, ist es zur am weitesten verbreiteten Schätzungsmethode in Agile geworden – und das aus gutem Grund.

Hier ist das Problem, das es löst. Ohne Planning Poker verfallen Schätzungssitzungen in einen von zwei Fehlermodi: Entweder spricht die ranghöchste Person zuerst und alle orientieren sich an ihrer Zahl, oder das Team streitet endlos ohne eine Einigung zu erreichen. Planning Poker behebt beides. Die gleichzeitige Aufdeckung eliminiert den Anker-Effekt, und die strukturierten Diskussionsrunden fördern produktive Gespräche über Komplexität, Unbekannte und Risiken.

Ob Sie Sprint Planning für ein neues Scrum Team durchführen oder die Schätzungsgenauigkeit in einem erfahrenen Team verbessern möchten, dieser Leitfaden deckt alles ab – vom Grundprozess bis zu fortgeschrittenen Moderationsstrategien, häufigen Fehlern und wann Sie besser einen anderen Ansatz verwenden sollten.

Schnellantwort: Planning Poker auf einen Blick

Aspekt	Details
Was es ist	Konsensbasierte Schätzungstechnik mit Karten mit Werten
Erfunden von	James Grenning (2002), populär gemacht von Mike Cohn
Kartenwerte	Modifizierte Fibonacci: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ☕
Zeit pro Story	2-5 Minuten (inkl. Diskussionsrunden)
Wer nimmt teil	Nur Developers schätzen; Product Owner klärt, stimmt aber nicht ab
Wann zu verwenden	Sprint Planning, Backlog Refinement Sitzungen
Hauptvorteil	Eliminiert Anker-Bias, fördert gemeinsames Verständnis
Genauigkeit	Forschung zeigt deutlich genauer als individuelle Schätzungen

Was ist Planning Poker?

Planning Poker ist eine agile Schätzungstechnik, bei der das Development Team Story Points für Product Backlog Einträge durch einen strukturierten kartenbasierten Prozess zuweist. Jedes Teammitglied hat ein Kartenset mit Zahlen aus der Fibonacci-Sequenz, wählt seine Schätzung privat aus, und dann decken alle gleichzeitig auf.

Die Schlüsselerkenntnis? Gleichzeitiges Aufdecken. Diese einzelne Designentscheidung eliminiert den Anker-Effekt – die gut dokumentierte kognitive Verzerrung, bei der Menschen ihr Denken basierend auf der ersten Zahl, die sie hören, anpassen.

Ursprünge und Geschichte

Planning Poker hat seine Wurzeln in der Wideband Delphi Technik, die in den 1940er Jahren bei der RAND Corporation entwickelt wurde. Diese Methode verwendete bereits unabhängige Schätzung gefolgt von Gruppendiskussion, aber sie war nicht für das schnelle Tempo der Softwareentwicklung konzipiert.

Im Jahr 2002 adaptierte James Grenning das Konzept zu dem, was wir heute Planning Poker nennen. Er veröffentlichte "Planning Poker, or How I Learned to Stop Worrying and Love the Estimate" – den Titel von Kubrick entlehnend – und beschrieb eine leichtgewichtige Technik, die natürlich in agile Sprints passte.

Mike Cohn popularisierte dann die Methode durch sein Buch von 2005 Agile Estimating and Planning, das zur Standardreferenz für agile Schätzungspraktiken wurde. Heute ist Planning Poker die dominierende Schätzungsmethode bei agilen Teams weltweit.

Warum es funktioniert: Die Wissenschaft dahinter

Drei Mechanismen machen Planning Poker effektiv:

1. Vermeidung von Anker-Bias Forschung von Kahneman und Tversky zeigte, dass Menschen die erste Information, die sie erhalten, stark gewichten. Bei traditionellen Schätzungsmeetings "verankert" die erste sprechende Person alle anderen Schätzungen. Das gleichzeitige Aufdecken von Planning Poker umgeht dies vollständig.

2. Weisheit der Menge Wenn Individuen unabhängig schätzen, bevor sie teilen, tendiert die Gruppenschätzung dazu, genauer zu sein als die jeder einzelnen Person. Dieser Effekt – dokumentiert von Surowiecki und anderen – erfordert unabhängiges Urteil gefolgt von Aggregation. Planning Poker liefert genau das.

3. Erzwungene Diskussion von Ausreißern Wenn Schätzungen divergieren (z.B. eine 3 und eine 13 für dieselbe Story), muss das Team seine Überlegungen erklären. Diese Gespräche decken häufig versteckte Annahmen, verpasste Anforderungen oder unterschiedliche Interpretationen der Story auf. Die Diskussion selbst ist oft wertvoller als die endgültige Zahl.

Der Planning Poker Prozess: Schritt für Schritt

Hier ist der vollständige Prozess, vom Setup bis zur finalen Schätzung.

Schritt 1: Präsentieren Sie die User Story

Der Product Owner liest die User Story laut vor und erklärt:

• Was die Story liefert (Benutzerwert)
• Akzeptanzkriterien (wie wir wissen, dass es fertig ist)
• Kontext – warum diese Story jetzt wichtig ist

Halten Sie es kurz. Das Ziel ist gemeinsames Verständnis, keine Spezifikationsüberprüfung. Zwei bis drei Minuten sind typischerweise ausreichend.

Schritt 2: Klärende Fragen stellen

Das Team stellt Fragen. Dies ist kritisch – überstürzen Sie es nicht. Häufige Fragen umfassen:

• "Beinhaltet dies das Backend-API oder nur das UI?"
• "Gibt es bestehende Muster, denen wir folgen können?"
• "Was passiert, wenn der externe Service nicht verfügbar ist?"

Der Product Owner beantwortet, was er kann. Bei technischen Fragen außerhalb seines Bereichs äußern sich Teammitglieder mit relevanter Expertise.

Schritt 3: Karten privat auswählen

Jedes Teammitglied wählt eine Karte aus ohne sie jemandem zu zeigen. Keine Diskussion, kein Spähen, keine Ankündigung. Diese Unabhängigkeit ist es, was die Technik funktionieren lässt.

Teammitglieder sollten berücksichtigen:

• Komplexität – Wie viele bewegliche Teile? Wie vernetzt?
• Unsicherheit – Wie gut verstehen wir die Anforderungen und Technologie?
• Aufwand – Wie viel Arbeit ist ungefähr involviert?

Schritt 4: Gleichzeitig aufdecken

Bei einem Countdown ("3, 2, 1, umdrehen!") zeigen alle gleichzeitig ihre Karten.

Wenn die Schätzungen nahe beieinander liegen (innerhalb einer Fibonacci-Zahl), nehmen Sie den höheren Wert und machen Sie weiter. Es ist nicht nötig, Übereinstimmung zu diskutieren – sparen Sie Zeit für die Stories, bei denen die Meinungen auseinandergehen.

Schritt 5: Die Unterschiede diskutieren

Wenn Schätzungen divergieren, erklären der höchste und niedrigste Schätzer ihre Überlegungen. Hier liegt der wahre Wert.

Typische Entdeckungen während der Diskussion:

• "Mir war nicht klar, dass wir das von Grund auf neu bauen müssen" – Jemand nahm eine bestehende Bibliothek an; jemand anderes weiß, dass sie nicht existiert
• "Diese Integration ist tatsächlich unkompliziert" – Die Person, die es vorher gemacht hat, teilt, dass es ein bekanntes Muster ist
• "Wir vergessen die Migration" – Eine versteckte Anforderung taucht auf

Der Scrum Master moderiert und stellt sicher, dass alle gehört werden und das Gespräch produktiv bleibt.

Schritt 6: Neu schätzen bis Konsens erreicht ist

Nach der Diskussion schätzt das Team erneut. Normalerweise führen ein oder zwei zusätzliche Runden zum Konsens.

Was zählt als Konsens? Nicht alle müssen sich auf genau dieselbe Zahl einigen. Wenn Sie vier 5en und eine 8 haben, ist das in Ordnung – gehen Sie mit 5 oder 8, je nach Vertrauen des Teams. Das Gespräch ist bereits passiert, was zählt.

Begrenzen Sie jede Story auf 5 Minuten. Wenn sich kein Konsens ergibt, entweder:

• Nehmen Sie die höhere Schätzung (sicherer)
• Verschieben Sie die Story für weitere Recherchen (Spike)
• Teilen Sie die Story in kleinere Teile

Planning Poker Kartenwerte erklärt

Die modifizierte Fibonacci-Skala

Die meisten Teams verwenden dieses Set: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100

Warum Fibonacci und nicht 1-10? Die wachsenden Lücken zwischen den Zahlen reflektieren, wie Unsicherheit mit der Größe zunimmt. Sie können den Unterschied zwischen einer 2-Punkte- und einer 3-Punkte-Story erkennen. Aber zu behaupten, etwas sei 47 vs. 48? Das ist falsche Präzision, die niemand braucht.

Punkte	Was es bedeutet	Ungefähre Dauer
0	Bereits erledigt oder triviale Konfigurationsänderung	Minuten
½	Winzig – Textänderung, einfacher Fix	Unter einer Stunde
1	Klein, gut verstandene Aufgabe	Ein paar Stunden
2	Klein mit geringer Komplexität	Halber Tag
3	Mittel, klarer Ansatz	Etwa ein Tag
5	Mittel-groß, einige Unbekannte	1-2 Tage
8	Groß, mehrere Komponenten	2-3 Tage
13	Sehr groß, bedeutende Unbekannte	3-5 Tage
20+	Zu groß – sollte geteilt werden	Erwägen Sie die Teilung

Spezielle Karten

• ? (Fragezeichen): "Ich habe nicht genug Informationen zum Schätzen." Dies ist keine Ausrede – es signalisiert, dass die Story mehr Verfeinerung braucht, bevor das Team sich verpflichten kann.
• ☕ (Kaffeetasse): "Ich brauche eine Pause." Lange Schätzungssitzungen verursachen Ermüdung. Respektieren Sie diese Karte.
• ∞ (Unendlich): "Diese Story ist zu groß oder zu vage, um überhaupt geschätzt zu werden." Zeit, sie aufzuteilen.

Alternative Skalen

Einige Teams bevorzugen unterschiedliche Skalen:

• T-Shirt-Größen: XS, S, M, L, XL – gut für grobe Roadmap-Schätzung
• Zweierpotenzen: 1, 2, 4, 8, 16, 32 – sauberer für manche Teams, obwohl die Sprünge unnatürlich wirken
• Fünf Finger: Halten Sie 1-5 Finger hoch – keine Karten nötig, funktioniert in informellen Settings

Die Fibonacci-Skala bleibt die beliebteste Wahl, weil sie die richtige Balance zwischen Präzision und Anerkennung von Unsicherheit schafft.

Planning Poker vs. andere Schätzungstechniken

Aspekt	Planning Poker	T-Shirt Sizing	Affinity Estimation	Individuelle Schätzung
Geschwindigkeit pro Item	2-5 Minuten	30-60 Sekunden	10-20 Sekunden	15-30 Sekunden
Beste Batch-Größe	10-20 Stories	20-50 Stories	50-200 Stories	Beliebig
Genauigkeit	Hoch	Mittel	Mittel	Niedrig
Team-Alignment	Hoch (diskussionsgetrieben)	Mittel	Mittel-Hoch	Keine
Bias-Schutz	Stark (gleichzeitiges Aufdecken)	Moderat	Moderat	Keiner
Am besten für	Sprint Planning, Refinement	Roadmap-Größenbestimmung, neue Teams	Große Backlog-Triage	Schnelle individuelle Triage
Velocity Tracking	Direkt (numerisch)	Erfordert Konvertierung	Erfordert Konvertierung	Direkt

Übliche Progression: Affinity Estimation für das initiale Backlog (100+ Stories) → T-Shirt Sizing für vierteljährliche Roadmap → Planning Poker für Sprint-Level Stories.

Planning Poker für Remote Teams durchführen

Planning Poker wurde für co-lokalisierte Teams mit physischen Karten entworfen. Aber die meisten Teams sind heute verteilt. So funktioniert es.

Synchrone Remote-Sitzungen

• Video an. Gesichter zu sehen hilft, Unsicherheit und Engagement zu erkennen.
• Bildschirm teilen der Story. Alle schauen gleichzeitig auf dieselben Akzeptanzkriterien.
• Verwenden Sie digitale Karten. Tools handhaben das gleichzeitige Aufdecken automatisch.
• Streng zeitbegrenzen. Remote-Ermüdung trifft schneller – halten Sie Sitzungen unter 60 Minuten.
• Stumm während privater Auswahl. Verhindern Sie verbale Verankerung ("hmm, das ist groß...").

Asynchrones Planning Poker

Für Teams über viele Zeitzonen hinweg kann asynchrone Schätzung funktionieren:

1. Product Owner postet Story mit Kontext in einem geteilten Kanal
2. Teammitglieder reichen Schätzungen innerhalb eines 24-Stunden-Fensters ein
3. Wenn Schätzungen konvergieren, wird der Konsens aufgezeichnet
4. Wenn Schätzungen divergieren, wird eine 15-minütige synchrone Diskussion nur für diese Stories geplant

Dieser Hybridansatz behandelt 70-80% der Stories asynchron und reserviert synchrone Zeit für die kontroversen.

Beliebte digitale Tools

Tool	Kostenlose Version	Jira Integration	Async Support	Am besten für
Parabol	Ja	Ja	Ja	Remote-First Teams
Planning Poker Online	Ja	Nein	Nein	Schnelle Sitzungen
Scrum Poker (Jira Plugin)	Testversion	Nativ	Nein	Jira-lastige Teams
Miro/Mural Templates	Ja	Nein	Ja	Visuelle Denker
Scrumpy Poker	Ja	Ja	Nein	Einfaches Setup

Häufige Planning Poker Fehler

Acht Fehler, die Schätzungssitzungen sabotieren – und wie man jeden einzelnen behebt.

Fehler 1: Product Owner stimmt über Schätzungen ab

Wie es aussieht: Der PO nimmt Karten auf und nimmt neben den Developers teil.

Warum es ein Problem ist: Selbst gut meinende POs erzeugen impliziten Druck. Wenn der PO eine 3 hochhält, könnten Developers, die 8 dachten, sich selbst zensieren, um nicht langsam zu wirken.

Lösung: Der Product Owner präsentiert die Story, beantwortet Fragen und beobachtet. Er stimmt nicht ab. Punkt. Wenn Ihr PO zurückdrängt, verweisen Sie ihn auf den Scrum Guide – nur Developers schätzen die Arbeit.

Fehler 2: Story Points als Zeitverpflichtungen behandeln

Wie es aussieht: "Du hast gesagt, das ist eine 5? Das bedeutet, es sollte bis Mittwoch fertig sein."

Warum es ein Problem ist: Story Points messen Komplexität, Unsicherheit und Aufwand kombiniert – nicht Kalenderzeit. Story Points in Stunden zu konvertieren, macht den gesamten Zweck zunichte.

Lösung: Verwenden Sie Velocity (durchschnittliche Story Points pro Sprint) für die Vorhersage von Lieferterminen. Konvertieren Sie niemals einzelne Story Points in Stunden.

Fehler 3: Mittelung statt Diskussion

Wie es aussieht: "Wir haben 3, 5, 5, 8, 13. Durchschnitt ist 6,8, nennen wir es 8."

Warum es ein Problem ist: Die Person, die 13 sagte, könnte von einer versteckten Abhängigkeit wissen. Die Person, die 3 sagte, könnte einen Shortcut kennen. Mittelung verwirft diese Informationen vollständig.

Lösung: Lassen Sie immer die höchsten und niedrigsten Schätzer ihre Überlegungen erklären, bevor neu geschätzt wird. Die Ausreißer halten oft die wertvollste Information.

Fehler 4: Marathon-Schätzungssitzungen

Wie es aussieht: Vierstündige Planning Poker Sitzungen, bei denen das Team 40+ Stories schätzt.

Warum es ein Problem ist: Die Schätzungsgenauigkeit sinkt deutlich nach 60-90 Minuten. Bei Story 30 spielen die Leute nur noch zufällig Karten, um es hinter sich zu bringen.

Lösung: Begrenzen Sie Sitzungen auf 60-90 Minuten und 15-20 Stories. Führen Sie laufendes Backlog Refinement durch, damit Sie nie Marathon-Sitzungen brauchen.

Fehler 5: Keine Referenz-Stories

Wie es aussieht: Jede Schätzung beginnt von vorne. "Ist das eine 5? Wie fühlt sich eine 5 überhaupt an?"

Warum es ein Problem ist: Ohne Kalibrierung könnte dasselbe Team ähnliche Stories eine Woche als 3 und die nächste als 8 schätzen. Velocity wird unvorhersehbar.

Lösung: Pflegen Sie ein "Referenz-Story-Poster" – 2-3 abgeschlossene Stories für jede Fibonacci-Zahl. Vor jeder Sitzung erinnern Sie das Team: "Erinnern Sie sich, unsere 5-Punkte-Referenz war die Zahlungsformular-Umgestaltung."

Fehler 6: Die Kaffee-Karte ignorieren

Wie es aussieht: Jemand spielt die ☕-Karte und der Moderator sagt "Wir machen eine Pause nach diesen nächsten fünf Stories."

Warum es ein Problem ist: Ein ermüdetes Team produziert schlechte Schätzungen. Die Kaffee-Karte existiert aus einem Grund.

Lösung: Respektieren Sie Pausenanfragen sofort. Besser 10 Minuten für eine Pause zu verlieren als einen Sprint wegen schlechter Schätzungen zu verschwenden.

Fehler 7: Abgeschlossene Stories neu schätzen

Wie es aussieht: "Diese 5-Punkte-Story dauerte tatsächlich eine volle Woche. Ändern wir sie auf 13."

Warum es ein Problem ist: Das Ändern historischer Schätzungen korrumpiert Velocity-Daten. Ihre Velocity sollte widerspiegeln, wie viel Sie dachten, Sie könnten tun vs. wie viel Sie tatsächlich getan haben – diese Lücke ist nützliche Information.

Lösung: Behalten Sie die ursprünglichen Schätzungen. Diskutieren Sie Fehlschätzungen in der Sprint Retrospective, um zukünftige Genauigkeit zu verbessern.

Fehler 8: Nebengespräche während Kartenauswahl erlauben

Wie es aussieht: Developers unterhalten sich über die Story beim Auswählen der Karten. "Ja, ich denke, das ist ziemlich groß..."

Warum es ein Problem ist: Dies führt Anker-Bias durch die Hintertür wieder ein. Selbst beiläufige Kommentare beeinflussen die Kartenauswahl.

Lösung: Erzwingen Sie Stille während der Kartenauswahl. Der Moderator sagt "Nur Karten, kein Sprechen" vor jeder Runde.

Wann NICHT Planning Poker verwenden

Planning Poker ist nicht universell. Überspringen Sie es, wenn:

• Solo-Entwickler: Sie können nicht alleine Poker spielen. Verwenden Sie stattdessen zeitbasierte Schätzung.
• Alle Stories haben ähnliche Komplexität: Wenn Sie 50 ähnliche Bug-Fixes abarbeiten, zählen Sie sie einfach. Keine Karten nötig.
• Spike/Recherche-Stories: Begrenzen Sie diese zeitlich ("4 Stunden für Recherche") statt in Punkten zu schätzen.
• Produktionsvorfälle: Reagieren Sie zuerst, schätzen Sie nie. Vorfälle sind keine geplante Arbeit.
• Sehr kleine Stories (alle 1-2 Punkte): Wenn Ihr Team durchweg zustimmt, dass Stories winzig sind, schätzen Sie sie in Batches.
• Kanban Continuous-Flow Teams: Teams, die reines Kanban verwenden, überspringen Story Points oft ganz und nutzen stattdessen Zykluszeit-Metriken.

Verwenden Sie stattdessen Affinity Estimation, wenn Sie 50+ Stories in einer einzigen Sitzung schätzen müssen. Verwenden Sie T-Shirt Sizing, wenn Stakeholder grobe Größenbestimmung für Roadmap-Gespräche benötigen.

Planning Poker Reife: Von Anfänger bis Fortgeschritten

Teams meistern Planning Poker nicht über Nacht. So sieht die Reise typischerweise aus.

Stufe 1: Die Basics lernen (Sprints 1-3)

Was zu erwarten ist:

• Hohe Schätzungsvarianz (Spreads von 1 bis 13 für dieselbe Story)
• Viele Diskussionsrunden (3-4 pro Story)
• Sitzungen laufen lang (Stories brauchen 10+ Minuten pro Story)
• Team denkt noch in Stunden, nicht in relativer Komplexität

Fokus auf:

• Mit Fibonacci-Zahlen vertraut werden
• Ihre ersten 3-5 Referenz-Stories etablieren
• Diskussionen produktiv halten (nicht argumentativ)
• Psychologische Sicherheit aufbauen, damit Junior-Mitglieder sich äußern

Stufe 2: Ihren Rhythmus finden (Sprints 4-10)

Was zu erwarten ist:

• Schätzungsvarianz schrumpft (typischer Spread von 1-2 Fibonacci-Zahlen)
• Die meisten Stories erreichen Konsens in 1-2 Runden
• Sitzungen werden vorhersehbar (2-4 Minuten pro Story)
• Velocity stabilisiert sich genug für grundlegende Vorhersagen

Fokus auf:

• Ihre Referenz-Story-Bibliothek erweitern
• Stories erkennen, die Teilung brauchen, bevor geschätzt wird
• Schätzungen mit Velocity für Release-Planung verbinden
• Asynchrone Schätzung für unkomplizierte Stories ausprobieren

Stufe 3: Schätzungsvertrauen (Sprint 11+)

Was zu erwarten ist:

• Einzel-Runden-Konsens bei den meisten Stories
• Team identifiziert natürlich Stories, die Teilung brauchen
• Schätzungssitzungen fühlen sich leichtgewichtig und schnell an
• Velocity ist stabil und vorhersehbar

Fokus auf:

• Kontinuierliche Kalibrierung – aktualisieren Sie Referenz-Stories jedes Quartal
• Probabilistische Vorhersage mit historischen Velocity-Daten
• Neue Teammitglieder mit etablierten Praktiken mentorieren
• Erwägen, ob manche Story-Typen formale Schätzung ganz überspringen können

Branchenbeispiele

Planning Poker passt sich verschiedenen Kontexten an. So nutzen es Teams in verschiedenen Branchen.

SaaS-Produktteams

Typische Story: "Als Admin möchte ich SSO über SAML konfigurieren, damit Enterprise-Kunden ihren Identity Provider nutzen können."

Schätzungsüberlegungen: API-Integrationskomplexität, Sicherheitsüberprüfungsanforderungen, Multi-Tenant-Implikationen, Dokumentationsbedarf.

Gängiges Muster: Die meisten Stories fallen in den 3-8-Bereich. Infrastruktur-Stories (Datenbankmigrationen, CI/CD-Änderungen) bekommen oft 13+, wegen teamübergreifender Koordination.

Healthcare-Software

Typische Story: "Als Arzt möchte ich die Medikamentenhistorie des Patienten mit Interaktionswarnungen sehen."

Schätzungsüberlegungen: HIPAA-Compliance-Anforderungen, Audit-Logging, Datenzugriffskontrollen, klinischer Workflow-Einfluss. Stories, die geschützte Gesundheitsinformationen (PHI) berühren, bekommen typischerweise höhere Schätzungen wegen Compliance-Verifizierung.

Gängiges Muster: Teams fügen "Compliance-Review" zu ihrer Definition of Done hinzu, was Schätzungen vs. nicht-regulierte Branchen aufbläht. Eine Story, die anderswo eine 5 sein könnte, ist hier eine 8.

E-Commerce-Plattformen

Typische Story: "Als Käufer möchte ich Ein-Klick-Nachbestellung aus meiner Bestellhistorie."

Schätzungsüberlegungen: Zahlungsverarbeitungsintegration (PCI-Compliance), Bestandsverfügbarkeitsprüfungen, Preisneuberechnung, mobile Responsiveness.

Gängiges Muster: Feature-Stories laufen 5-13 Punkte. Performance-Optimierungs-Stories sind schwerer zu schätzen, weil der Umfang von Profiling-Ergebnissen abhängt – diese werden oft zuerst Spikes.

Mobile-App-Entwicklung

Typische Story: "Als Benutzer möchte ich Push-Benachrichtigungen für Bestellstatus-Updates erhalten."

Schätzungsüberlegungen: iOS- und Android-Unterschiede, Push-Notification-Service-Integration, Hintergrundprozess-Handling, Benachrichtigungspräferenz-Management, App-Store-Richtlinien-Compliance.

Gängiges Muster: "Dasselbe Feature, zwei Plattformen" Stories brauchen oft separate Schätzungen. Eine 5-Punkte Android-Story könnte 8 Punkte auf iOS sein (oder umgekehrt), abhängig von plattformspezifischen Herausforderungen.

FinTech / Banking

Typische Story: "Als Benutzer möchte ich wiederkehrende Überweisungen zwischen meinen Konten einrichten."

Schätzungsüberlegungen: Transaktionsverarbeitung, Betrugserkennung-Integration, regulatorische Compliance (SOC 2, PCI-DSS), Verschlüsselungsanforderungen, Prüfpfad.

Gängiges Muster: Compliance- und Sicherheitsanforderungen bedeuten, dass FinTech-Stories durchweg höher geschätzt werden. Teams pflegen oft separate Referenz-Stories für "compliance-lastige" vs. "Standard"-Features.

Regierung / Öffentlicher Sektor

Typische Story: "Als Bürger möchte ich meinen Genehmigungsantrag online einreichen."

Schätzungsüberlegungen: Section 508 Barrierefreiheits-Compliance, FISMA-Sicherheitsanforderungen, Mehrsprachenunterstützung, Legacy-System-Integration.

Gängiges Muster: Legacy-System-Integration ist der Joker. Teams lernen schnell, eine "Legacy-Integrations-Steuer" zu ihren Schätzungen hinzuzufügen, wenn APIs schlecht dokumentiert oder unzuverlässig sind.

Best Practices für effektive Sitzungen

Vor der Sitzung:

• Verfeinern Sie Stories vor der Schätzung – vage Stories produzieren vage Schätzungen
• Teilen Sie Stories 24 Stunden im Voraus, damit das Team vorausdenken kann
• Posten Sie Referenz-Stories, wo alle sie sehen können

Während der Sitzung:

• Begrenzen Sie jede Story auf 5 Minuten (inkl. Diskussion)
• Lassen Sie die höchsten und niedrigsten Schätzer zuerst sprechen
• Wenn es unklar ist, verschieben Sie – erzwingen Sie keine Zahl
• Verfolgen Sie, welche Stories hohe Varianz hatten (überprüfen in Retro)

Nach der Sitzung:

• Erfassen Sie Schätzungen sofort in Ihrem Backlog-Tool
• Notieren Sie alle Stories, die für mehr Informationen verschoben wurden
• Markieren Sie Stories mit anhaltend hoher Varianz für den Product Owner

Moderationstipps:

• Rotieren Sie die Moderatorrolle, um gemeinsame Eigentümerschaft aufzubauen
• Verwenden Sie Humor – Planning Poker sollte sich wie ein Spiel anfühlen, nicht wie ein Meeting
• Achten Sie auf "Schätzungsermüdung" – kürzere, häufigere Sitzungen schlagen Marathons
• Neue Teammitglieder sollten 1-2 Sitzungen beobachten, bevor sie teilnehmen

Fazit

Planning Poker funktioniert, weil es respektiert, wie Menschen tatsächlich denken. Das gleichzeitige Aufdecken verhindert Anker-Bias. Die Diskussionsrunden decken versteckte Komplexität auf. Die Fibonacci-Skala erkennt an, dass größere Aufgaben mehr Unsicherheit tragen.

Wichtigste Erkenntnisse:

1. Gleichzeitiges Aufdecken ist nicht verhandelbar – es ist der Mechanismus, der Bias verhindert
2. Diskussion zählt mehr als die Zahl – das Gespräch deckt Risiken und Annahmen auf
3. Nur Developers schätzen – der Product Owner klärt, stimmt aber nicht ab
4. Verwenden Sie Referenz-Stories zur Kalibrierung – "Wie fühlt sich eine 5 tatsächlich in diesem Team an?"
5. Begrenzen Sie jede Story auf 5 Minuten – wenn Sie keinen Konsens erreichen können, braucht die Story Teilung oder einen Spike
6. Konvertieren Sie Punkte nicht in Stunden – verwenden Sie Velocity für Vorhersagen stattdessen
7. Passen Sie die Technik dem Kontext an – verwenden Sie Planning Poker für Sprint-Level Stories, Affinity Estimation für große Backlogs, T-Shirt Sizing für Roadmaps

Beginnen Sie mit den Basics: besorgen Sie sich ein Kartenset (physisch oder digital), etablieren Sie 3-5 Referenz-Stories und führen Sie Ihre erste Sitzung durch. Sie werden Fehler machen – jedes Team macht das. Aber nach ein paar Sprints werden Sie sich fragen, wie Sie jemals ohne es geschätzt haben.

Weiterführende Literatur

Häufig gestellte Fragen

Häufig gestellte Fragen (FAQs)