Warum wir schätzen: Der wahre Wert von Planning Poker jenseits von Zahlen
Jedes agile Team durchläuft irgendwann eine Phase, in der unweigerlich jemand die Frage stellt:
„Warum machen wir uns überhaupt die Mühe mit Story Points? Können wir das Ticket nicht einfach durchsprechen, uns einig sein und direkt mit dem Entwickeln anfangen?“
Das klingt im ersten Moment verlockend pragmatisch. Schätzen kann sich schnell wie ein bürokratisches Ritual anfühlen – besonders dann, wenn Story Points mit Deadlines oder Leistungsnachweisen für Management-Dashboards verwechselt werden. Die bekannten #NoEstimates-Debatten gibt es schließlich nicht ohne Grund.
Doch wenn ich Refinements moderiere oder Teams beobachte, die mit Teamprove Meet* arbeiten, zeigt sich ein faszinierendes Muster: *Teams, die das Schätzen komplett abschaffen, sparen keine Zeit. Sie verschieben die Reibung lediglich in die Mitte des Sprints.
Hier ist der Grund, warum reines Durchsprechen oft in eine Falle führt – und warum der eigentliche Wert von Planning Poker nicht in der Zahl liegt, sondern in dem Denkprozess davor.
---
Die „Illusion von Einigkeit“ in rein verbalen Refinements
Erinnern Sie sich an ein typisches Remote-Refinement, in dem auf Schätzrunden verzichtet wird:
1. Der Product Owner oder Tech Lead teilt den Bildschirm, scrollt durch das Ticket und erklärt die Anforderungen. 2. Es folgt die klassische Frage: „Haben alle verstanden, worum es geht? Gibt es noch Fragen?“ 3. Drei Sekunden höfliches, unangenehmes Schweigen. Zwei Personen nicken vor der Kamera. 4. Das Ticket wird auf Ready for Dev gesetzt und man geht zur nächsten Story über.
Das Meeting fühlte sich schnell und harmonisch an. Doch was hier stattgefunden hat, ist fast immer die Illusion von Einigkeit.
In der Kognitionspsychologie ist bekannt: Passive verbale Präsentationen lösen in einer Gruppe selten tiefgehende analytische Reflexion aus. Nur die sprechende Person – und vielleicht noch ein erfahrener Lead-Entwickler – hat die technische Architektur im Kopf wirklich simuliert. Der Rest des Teams nickt höflich mit, während die Gedanken längst zu Slack oder in die IDE wandern.
Schweigen im Video-Call bedeutet fast nie Konsens; meistens ist es kognitive Überlastung, Höflichkeit oder die Hemmung, vor dem Team eine vermeintlich banale Frage zu stellen.
---
Was der Akt des Schätzens im Gehirn auslöst
Die Magie von Planning Poker liegt nicht im finalen Fibonacci-Wert. Die Zahl ist schlicht der Vorwand, um jedes Teammitglied zur mentalen Simulation zu zwingen.
In dem Moment, in dem die Moderation sagt: „Karten verdeckt wählen – bitte abstimmen!“, kippt die Dynamik im Raum schlagartig:
- Man kann nicht mehr bloß nicken. Jeder muss eine Karte wählen. - Um eine Zahl zu wählen, muss man die Story gedanklich bauen. Das Gehirn springt sofort in die Tiefenprüfung: „Moment mal, haben wir dafür überhaupt einen fertigen API-Endpunkt? Brauchen wir eine Datenbankmigration? Was passiert, wenn der externe Webhook ausfällt? Wer testet die Edge Cases?“ - Gleiche mentale Beteiligung. Schätzen fordert die Denkleistung aller ein – nicht nur der lautesten Stimmen oder der Autoren des Tickets.
Die Schätzung verwandelt einen passiven Monolog in ein aktives, synchrones Denk-Ritual.
---
Was die Daten zeigen: Das Gold liegt in der Diskrepanz
In den Session-Daten von Zehntausenden Schätzrunden in Teamprove Meet beobachten wir ein klares Muster beim Aufdecken der Karten:
Typischer Reveal bei verdeckter Schätzung:
Entwicklerin A (Frontend): [ 2 ]
Entwickler B (Fullstack): [ 3 ]
Entwickler C (Backend): [ 8 ] <-- Das diagnostische SignalIn einer rein verbalen Diskussion hätte Entwickler C wahrscheinlich geschwiegen, in der Annahme, dass das Backend-Thema bestimmt schon geklärt sei.
Bei der verdeckten Schätzung ist die Diskrepanz sofort für alle sichtbar. Die Telemetrie von Teamprove Meet zeigt: In über 71 % der Fälle mit hoher Spreizung (z. B. 2 vs. 8) konvergiert das Team in der zweiten Runde nach oben oder beschließt, die Story zu teilen.
Warum? Weil Entwickler C die 8 nicht gewählt hat, um zu bremsen – sondern weil ihm eine unmigrierte Datenbanktabelle oder ein veraltetes Authentifizierungstoken eingefallen ist.
Wenn die Moderation nun fragt: „Entwicklerin A, warum eine 2? Entwickler C, warum eine 8?“, beginnt das eigentliche Refinement. Man streitet nicht darum, wer rechnerisch recht hat; man deckt kritische Annahmen auf, bevor auch nur eine einzige Zeile Code geschrieben wird.
---
Eine Coaching-Erfahrung: Der Monat ohne Schätzungen
Vor einigen Jahren coachte ich das Entwicklungsteam eines stark wachsenden Scale-ups, das von zähen Schätzrunden frustriert war. Sie starteten ein vierwöchiges Experiment: Absoluter Schätz-Stopp. Tickets sollten nur noch besprochen werden, bis niemand mehr Fragen hatte, und wanderten dann direkt in den Sprint.
Die erste Woche fühlte sich befreiend an: Das Refinement dauerte 20 statt 45 Minuten.
In der dritten Woche folgte das böse Erwachen: - Die Sprint-Velocity brach völlig ein. - Unfertige Tickets am Sprint-Ende stiegen von unter 10 % auf fast 45 %. - Am Mittwochnachmittag häuften sich die Slack-Nachrichten: „Moment, hast du gesehen, dass dieses Ticket das Zahlungs-Gateway betrifft? Das ist überhaupt kein Quick-Fix!“
Die Reibung war nicht verschwunden. Sie hatte sich lediglich von einem entspannten 3-Minuten-Gespräch im Refinement in stressige Notfall-Einsätze mitten im Sprint verlagert.
Als wir Planning Poker mit klaren Timeboxen wiedereinführten, kehrte die Planungssicherheit sofort zurück. Nicht weil Fibonacci-Karten magische Kräfte besitzen, sondern weil die Verpflichtung auf eine persönliche Schätzung alle unbequemen Fragen frühzeitig an die Oberfläche holte.
---
3 Regeln für leichtfüßige Schätzungen ohne Bürokratie
Wenn Ihr Team von Story Points genervt ist, schaffen Sie nicht die Karten ab – verbessern Sie die Moderation:
1. Konzentrieren Sie sich auf die Differenz, nicht auf Mathe: Wenn alle eine 3 wählen, verlieren Sie keine Sekunde mit der Diskussion, ob es vielleicht eine 2 sein könnte. Bestätigen Sie die 3 und weiter geht's. Diskutieren Sie nur die Spreizung zwischen der niedrigsten und der höchsten Karte. 2. Keine Punkte für Leistungsvergleiche: Story Points messen Komplexität und Unsicherheit relativ zu Ihrer Team-Baseline – sie sind weder geleistete Arbeitsstunden noch ein Entwickler-Ranking. 3. Konsequente Timeboxen nutzen: Geben Sie dem Team 60 Sekunden für die verdeckte Stimmabgabe. Dauert eine Diskussion über Ausreißer länger als 3 Minuten, lagern Sie das Thema als Research-Spike aus.
---
Fazit
Das eigentliche Ziel von Planning Poker war nie, dem Management eine millimetergenaue Zukunftsprognose zu liefern.
Es geht um geteiltes Verständnis, aktive Beteiligung aller Teammitglieder und die frühzeitige Entdeckung von Risiken. Wer die Schätzung weglässt, nimmt den mentalen Auslöser weg, der alle zum Mitdenken bringt.
Behalten Sie die Karten, halten Sie die Diskussionen fokussiert und freuen Sie sich über unterschiedliche Schätzungen – denn genau dort entstehen die wertvollsten technischen Erkenntnisse.