Beiträge

Wie man Meinungsverschiedenheiten während Planning Poker handhabt

Ein diverses Agile-Team sitzt um einen Tisch während einer Planning-Poker-Sitzung, hält Karten mit unterschiedlichen Schätzungen hoch, die Uneinigkeit zeigen, mit einem Scrum Master, der die Diskussion moderiert Sie decken die Karten auf. Ein Entwickler hat eine 3 gespielt. Ein anderer eine 13. Der Raum ist für eine Sekunde still, dann fangen alle an, gleichzeitig zu sprechen. Wenn Sie Planning Poker seit längerer Zeit moderieren, kennen Sie diesen Moment gut. Die meisten Scrum Master behandeln es als ein Problem, das schnell gelöst werden muss. Zum Konsens kommen, zur nächsten Story übergehen. Aber die Meinungsverschiedenheit selbst ist der wertvollste Teil der gesamten Sitzung. Die Lücke zwischen einer 3 und einer 13 bedeutet, dass Ihr Team grundlegend unterschiedliche Annahmen über die Arbeit hat, und diese Annahmen vor dem Sprint zu offenbaren ist genau das, wofür Schätzung da ist. Hier erfahren Sie, wie Sie diese Meinungsverschiedenheiten in bessere Sprint-Ergebnisse umwandeln, anstatt die Zeit zu verschwenden.

Warum Schätzungsabweichungen wertvoll sind

Wenn Ihr Team sich auf jede Schätzung sofort einig wäre, würde es Planning Poker überhaupt nicht brauchen. Sie könnten einfach eine Person Nummern zuweisen lassen. Der Grund dafür, dass gleichzeitige Offenbarung existiert, ist speziell um Meinungsverschiedenheit zu offenbaren. Wenn Schätzungen auseinandergehen, bedeutet dies normalerweise eines von drei Dingen: Verborgene Komplexität. Ein Entwickler sieht eine unkomplizierte CRUD-Operation. Ein anderer sieht einen Edge Case mit Concurrency oder eine fragile Integration, die sorgfältig gehandhabt werden muss. Ohne die Meinungsverschiedenheit würde das Team sich auf die niedrigere Schätzung einigen und die Komplexität mitten im Sprint entdecken. Unterschiedliche Annahmen über den Umfang. "Suchfunktion bauen" bedeutet Volltext-Suche mit Filtern und Pagination für einen Entwickler und ein einfaches String-Match-Dropdown für einen anderen. Die Lücke in den Schätzungen zeigt, dass die Akzeptanzkriterien geklärt werden müssen, bevor das Team mit dem Bau beginnt. Fehlende Anforderungen. Eine große Spanne signalisiert oft, dass die Story selbst unvollständig ist. Wenn jemand hoch schätzt, weil er Unbekannte berücksichtigt, die andere nicht in Betracht gezogen haben, müssen diese Unbekannten benannt und gelöst werden.

Die Ausreißer-Diskussionstechnik

Der einzeln effektivste Moderations-Schritt während Planning Poker ist, die Ausreißer zuerst sprechen zu lassen. Nach dem Offenbaren der Karten, beginnen Sie immer mit der Person, die am höchsten geschätzt hat, und der Person, die am niedrigsten geschätzt hat. Dies funktioniert aus drei Gründen:

1. Es gibt den Ausreißern das Wort. In vielen Teams wird die Person, die eine 2 gespielt hat, während alle anderen eine 8 spielten, ruhig bleiben, wenn sie nicht speziell eingeladen wird zu erklären. Sie könnten etwas wissen, das niemand sonst bedacht hat, oder sie könnten die Story missverstehen. In jedem Fall müssen Sie von ihnen hören.
2. Es verhindert, dass die Mehrheit die Ausreißer überrennt. Wenn fünf Personen eine 8 spielten und eine 2, ist der natürliche Instinkt, den Ausreißer unter Druck zu setzen, sich anzupassen. Mit dem Ausreißer zu beginnen signalisiert, dass ihre Perspektive zählt, unabhängig von den Nummern.
3. Es konzentriert die Diskussion. Anstatt eines freien Durcheinanders, bei dem jeder seine Begründung wiederholt, bekommen Sie eine strukturierte Debatte zwischen den beiden Enden des Spektrums. Der Rest des Teams hört zu und passt sein mentales Modell an.

Zwei Software-Entwickler haben eine respektvolle, engagierte Diskussion über einen Laptop-Bildschirm, einer zeigt auf den Bildschirm und erklärt seinen technischen Ansatz, während der andere nachdenklich zuhört, mit Schätzungskarten sichtbar auf einem Whiteboard

Wie man die Ausreißer-Diskussion moderiert

Verwenden Sie diese spezifischen Fragen, um produktive Ausreißer-Gespräche zu führen:

• Zum niedrigsten Schätzer: "Führen Sie uns durch Ihren Ansatz. Wie sieht diese Story in Ihrem Kopf aus?"
• Zum höchsten Schätzer: "Welche Risiken oder Komplexität sehen Sie, die möglicherweise nicht offensichtlich sind?"
• Zu beiden: "Welche Annahmen treffen Sie über den Umfang?"
• Nach beiden Aussagen: "Möchte jemand seine Schätzung basierend auf das ändern, was Sie gerade gehört haben?"

Dann neu abstimmen. Meistens konvergiert das Team nach einer Runde Ausreißer-Diskussion, weil das Gespräch entweder ein Missverständnis des Umfangs oder ein technisches Risiko offenbarte, das das mentale Modell aller ändert.

Häufige Ursachen für Meinungsverschiedenheiten

Das Verstehen, warum Schätzungen auseinandergehen, hilft Ihnen, Meinungsverschiedenheiten schneller zu lösen. Hier sind die Muster, die Sie am häufigsten sehen werden:

Unterschiedliches Verständnis des Umfangs

Dies ist die häufigste Ursache. Zwei Entwickler lesen die gleiche User Story und stellen sich völlig unterschiedliche Arbeiten vor. Einer interpretiert "Benachrichtigungen hinzufügen" als In-App-Toast-Nachricht. Ein anderer interpretiert es als E-Mail-Benachrichtigungen mit Vorlagen, Lieferverfolgung und Abmeldungsverwaltung. Wie man es löst: Bitten Sie den Product Owner, den Umfang auf der Stelle zu klären. Wenn der PO nicht im Raum ist, parken Sie die Story und bringen Sie sie zur nächsten Backlog Refinement-Sitzung.

Unterschiedliche technische Ansätze

Zwei Entwickler könnten sich auf den Umfang einigen, aber nicht darauf, wie sie ihn bauen sollen. Einer plant, einen vorhandenen Service zu erweitern. Ein anderer glaubt, dass der vorhandene Service die Last nicht handhaben kann und will einen neuen bauen. Wie man es löst: Das ist kein Schätzungsproblem; es ist eine Designentscheidung. Lassen Sie das Team die Vor- und Nachteile kurz besprechen und wählen Sie einen Ansatz. Wenn mehr Recherche nötig ist, erstellen Sie einen Spike und schätzen Sie die Story in der nächsten Sitzung.

Erfahrungslücken

Ein Senior Developer, der ähnliche Features schon gebaut hat, schätzt eine 3. Ein Mid-Level Developer, der nie mit diesem Teil der Codebasis gearbeitet hat, schätzt eine 8. Beide sind ehrlich, und beide haben Recht, basierend auf ihrer eigenen Erfahrung. Wie man es löst: Schätzen Sie für das Team, nicht für das Individuum. Fragen Sie: "Wenn ein typisches Teammitglied das aufgreifen würde, wie viel Aufwand ist es?" Wenn nur eine Person die Arbeit tun kann, ist das ein Wissensfreigabe-Risiko, das erwähnenswert ist, aber die Schätzung nicht aufblähen sollte. Die Schätzung sollte die innewohnende Komplexität widerspiegeln, nicht wer zufällig die Arbeit tut.

Unklar Akzeptanzkriterien

Wenn Stories vage sind, werden Schätzungen zu Vermutungen. "Leistung verbessern" ohne Zielzahl. "Dashboard benutzerfreundlicher machen" ohne Mockups. Diese Stories sind nicht bereit für Schätzung. Wie man es löst: Schicken Sie sie zurück. Stories, die nicht geschätzt werden können, sollten zur Verfeinerung zurückkehren. Wenn Sie dieses Muster häufig sehen, könnte das Problem in wie User Stories geschrieben werden liegen. Sie können auch einen Schätzungs-Komplexitätsanalysator verwenden, um unterbestimmte Stories zu kennzeichnen, bevor sie den Schätzungstisch erreichen.

Timeboxen Sie Ihre Schätzungsdiskussionen

Hier ist, wo die meisten Moderationen schiefgehen. Eine Meinungsverschiedenheit wird sichtbar, die Diskussion ist zwei Minuten lang produktiv, und dann läuft sie in eine 15-minütige Architektur-Debatte aus. Das Team schätzt vier Stories in einer Stunde statt zwölf. Legen Sie eine harte fünfminütige Timebox pro Story fest. Hier erfahren Sie, wie Sie sie durchsetzen: Ein Nahaufnahme-Overhead-Shot eines Konferenztisches mit Planning-Poker-Karten mit unterschiedlichen Schätzungen, einer Uhr und Sticky Notes mit User-Story-Text, die strukturierte Schätzungs-Debatte vermitteln

Warum Sie Schätzungen niemals durchschnittlich sollten

Wenn ein Team sich nicht einigen kann, ist es verlockend, den Unterschied zu teilen. "Wir haben eine 5 und eine 13, nennen wir es eine 8." Das fühlt sich fair und effizient an. Das ist es nicht. Durchschnitt versteckt die Meinungsverschiedenheit anstatt sie zu lösen. Die Person, die 13 gesagt hat, hat Informationen über Risiken oder Komplexität, die nicht verschwinden, weil Sie 8 aufgeschrieben haben. Wenn der Sprint beginnt, sind diese Risiken immer noch da, und das Team hat sich zu einer Schätzung verpflichtet, die weder Perspektive genau widerspiegelt. Durchschnitt besiegt auch den Zweck der Verwendung einer nicht-linearen Skala wie Fibonacci. Die Sprünge zwischen Werten (1, 2, 3, 5, 8, 13, 21) sind absichtlich groß, um Teams zu bedeutungsvollen Unterscheidungen zu zwingen. Eine 5 und eine 13 sind nicht "nah genug beieinander, um sich in der Mitte zu treffen." Sie vertreten grundlegend unterschiedliche Verständigungen der Arbeit. Für mehr darüber, warum Story-Point-Skalen so gestaltet sind, siehe unseren tiefgehenden Artikel. Was Sie statt Durchschnitt tun sollten:

• Verwenden Sie die Ausreißer-Diskussionstechnik, um die Grundursache der Meinungsverschiedenheit zu offenbaren
• Wenn Sie sich auf eine Zahl ohne Konsens einigen müssen, gehen Sie mit der höheren Schätzung. Es ist sicherer zu überschätzen als zu unterschätzen
• Wenn die Lücke extrem ist (z. B. 2 vs. 21), ist die Story nicht bereit. Schicken Sie sie zurück zur Verfeinerung

Verwenden Sie gleichzeitige Offenbarung, um Verankerungsbias zu verhindern

Verankerungsbias ist die Tendenz, stark auf die erste Information zu vertrauen, die Sie hören. Bei der Schätzung bedeutet dies, dass die erste laut ausgesprochene Zahl zum Anker für das Denken aller wird. Wenn ein Senior Developer sagt "das fühlt sich wie eine 3 an", bevor die Karten offenbart werden, passt der Rest des Teams unbewusst diese Zahl an. Anonymes Planning Poker löst dies, indem sichergestellt wird, dass alle Schätzungen eingereicht werden, bevor eine offenbart wird. Niemand sieht die Nummer von jemandem anderem, bis alle sich festgelegt haben. Das ist nicht nur ein schönes Extra; es ist eine strukturelle Schutzmaßnahme gegen einen der am besten dokumentierten kognitiven Bias bei der Entscheidungsfindung. Tools wie Kollabe erzwingen automatisch gleichzeitige Offenbarung. Karten bleiben verborgen, bis jeder Teilnehmer seine Schätzung ausgewählt hat. Das ist erheblich zuverlässiger als physische Karten, bei denen jemand unweigerlich früh aufdeckt oder die Karte in einem Winkel hält. Teams, die psychologische Sicherheit fehlt, profitieren besonders von anonymer Schätzung. Wenn Junior Developers das Gefühl haben, dass ihre ehrliche Schätzung von Senior Teammitgliedern beurteilt werden könnte, greifen sie auf das zurück, was die Seniors spielen. Anonymität entfernt diese Dynamik vollständig.

Wann Sie mit Diskutieren aufhören und die Story aufteilen sollten

Manchmal ist eine Meinungsverschiedenheit nicht ein Missverständnis. Beide Seiten verstehen die Story vollständig, aber die Arbeit ist wirklich komplex und unsicher. Wenn das passiert, ist die Antwort nicht eine längere Debatte. Die Antwort ist, die Story aufzuteilen. Zeichen, dass eine Story eher aufgeteilt als weiter diskutiert werden sollte:

• Schätzungen umfassen mehr als drei Fibonacci-Werte (z. B. 3 bis 21)
• Die Diskussion kommt immer wieder auf "es hängt davon ab..." mehrere Szenarien zurück
• Verschiedene Teile der Story könnten unabhängig bereitgestellt werden
• Das Team identifiziert verschiedene Risikobereiche, die isoliert werden könnten

Wie man effektiv aufteilt: Teilen Sie nach Wertelinien auf, nicht nach technischen Schichten. "API bauen" und "UI bauen" sind keine guten Aufteilungen, weil keine allein Benutzerwert liefert. Teilen Sie stattdessen nach Benutzerszenario: "Nach Name suchen" und "Mit erweiterten Filtern suchen" liefern jeweils etwas, das ein Benutzer tatsächlich nutzen kann. Nach der Aufteilung schätzen Sie jedes Stück neu. Sie werden oft feststellen, dass die Summe der Teile größer ist als die ursprüngliche Schätzung, und das ist in Ordnung. Die ursprüngliche Schätzung war falsch, weil die Story zu groß war, um genau zu schätzen. Kleinere Stories sind leichter zu schätzen, zu bauen und zu überprüfen.

Die Konfidenz-Abstimmungs-Technik

Sie haben die Ausreißer diskutiert, neu abgestimmt und eine Zahl erreicht, der das Team zustimmt. Aber Zustimmung ist nicht dasselbe wie Vertrauen. Die "Faust von fünf" Konfidenz-Abstimmung fängt den Unterschied auf. Nach dem Erreichen von Konsens bei einer Schätzung, bitten Sie jedes Teammitglied, gleichzeitig ein bis fünf Finger hochzuhalten:

Finger	Bedeutung
5	Vollständig zuversichtlich, keine Bedenken
4	Zuversichtlich, geringe Unsicherheit
3	Akzeptabel, einige Vorbehalte
2	Unbequem, erhebliche Bedenken
1	Stark anderer Meinung, sollte nicht verpflichtet werden

Wenn jemand 1 oder 2 zeigt, bekommt er 60 Sekunden, um sein Bedenken zu erklären. Oft wird dadurch ein Risiko sichtbar, das das Team beachten sollte, auch wenn die Schätzung nicht ändert, wie eine Abhängigkeit von einem anderen Team oder ein Stück Legacy-Code, der sich ändern könnte. Dies dauert 15 Sekunden pro Story, wenn das Vertrauen hoch ist, und addiert nur Zeit hinzu, wenn es ein Bedenken gibt, das es zu hören gilt. Es ist ein kostengünstiges Sicherheitsnetz gegen stilles Uneinigkeit.

Zusammenführung: Eine Moderations-Checkliste

Meinungsverschiedenheiten während Planning Poker sind kein Zeichen von Dysfunktion. Sie sind der Mechanismus, durch den Ihr Team ein gemeinsames Verständnis aufbaut. Das Ziel ist nicht, Meinungsverschiedenheit auszuschließen. Es ist, einen strukturierten Weg zu haben, die Information zu extrahieren, die die Meinungsverschiedenheit enthält, und sie in bessere Schätzungen und bessere Sprint-Ergebnisse umzuwandeln. Für einen umfassenden Blick auf Schätzungsansätze über Planning Poker hinaus, siehe unseren Leitfaden zu Agile Schätzungs-Techniken.