Wie man Planning Poker Schritt für Schritt durchführt
Bereiten Sie das Backlog vor, stimmen Sie unabhängig ab, diskutieren Sie bedeutende Unterschiede und verlassen Sie jede Runde mit einer vom Team getragenen Schätzung.

Planning Poker funktioniert, wenn die Karten eine sinnvolle Unterhaltung erzeugen – nicht wenn das Team versucht, die „richtige“ Zahl zu erraten. Eine gute Sitzung stellt sicher, dass alle denselben Backlog-Kontext haben, schützt die unabhängige Einschätzung bis zur Enthüllung und nutzt unterschiedliche Schätzungen, um Annahmen aufzudecken, bevor die Arbeit in einen Sprint geht.
Diese Anleitung bietet Ihnen eine wiederholbare Agenda für einen Moderator, einen Product Owner oder Backlog-Verantwortlichen sowie die Personen, die bei der Umsetzung der Arbeit helfen.
In dieser Anleitung
- Die Kurzfassung
- Backlog und Teilnehmer vorbereiten
- Praktische 45-Minuten-Agenda verwenden
- Jeden Punkt kalibrieren und präsentieren
- Abstimmen, Karten aufdecken und Streuung diskutieren
- Erneut abstimmen, aufteilen oder pausieren
- Beispiel mit fünf Punkten überprüfen
- Häufige Fehler vermeiden
- Moderatoren-Checkliste verwenden
Die Kurzfassung
Für jeden Backlog-Eintrag:
- Erklären Sie das Nutzerergebnis, den Umfang und die Akzeptanzkriterien.
- Ermöglichen Sie dem Team klärende Fragen zu stellen.
- Bitten Sie jede schätzende Person, eine Karte privat auszuwählen.
- Decken Sie alle Karten zusammen auf.
- Wenn die Streuung relevant ist, hören Sie die Begründungen für die niedrigen und hohen Schätzungen.
- Klären Sie den Eintrag, teilen Sie ihn bei Bedarf auf und stimmen Sie erneut ab.
- Erfassen Sie die Schätzung, auf die sich das Team geeinigt hat, und fahren Sie mit dem nächsten Punkt fort.
Planning Poker ist eine Schätzpraxis, kein verpflichtendes Scrum-Event. Der aktuelle Scrum Guide überlässt die Methoden zur Größenbestimmung dem Team, betont jedoch, dass diejenigen, die die Arbeit ausführen, für die Schätzung der Product-Backlog-Elemente verantwortlich sind.
Vor der Sitzung: Arbeit vorbereiten, die diskutiert werden kann
Ein Abstimmungsraum kann einen Backlog-Punkt, den niemand versteht, nicht ausgleichen. Bereiten Sie lieber eine kleine Anzahl kurzfristiger Punkte vor, anstatt das gesamte Backlog einzubringen.
Stellen Sie bei jedem Punkt sicher, dass das Team Folgendes sehen kann:
- das Nutzer- oder Geschäftsergebnis;
- was eingeschlossen und ausdrücklich ausgeschlossen ist;
- Akzeptanzkriterien oder ein Beispiel für erwartetes Verhalten;
- bekannte Abhängigkeiten, Einschränkungen und betroffene Systeme;
- offene Fragen, die die Größe beeinflussen könnten;
- bei Relevanz ein Link zu unterstützenden Designs oder technischem Kontext.
Entfernen Sie nicht jede Ungewissheit vor der Schätzung. Ungewissheit ist Teil dessen, was die Schätzung aufzeigen sollte. Das Team benötigt jedoch genug Kontext, um ein kleines Implementierungsdetail von einer ungelösten Produktentscheidung unterscheiden zu können.
Wählen Sie eine Skala, bevor die Abstimmung beginnt
Viele Teams verwenden eine Fibonacci-ähnliche Reihe wie 1, 2, 3, 5, 8, 13, 21. Die zunehmenden Abstände spiegeln wider, dass das Vertrauen meist abnimmt, wenn Arbeit größer oder weniger verstanden wird. Agilo unterstützt auch andere integrierte Skalen und benutzerdefinierte Kartensets.
Behandeln Sie Story Points als relative, teamspezifische Größen. Eine 5 ist nützlich, weil das Team versteht, wie sie im Vergleich zur eigenen 2 oder 8 steht; es ist keine universelle Stundenzahl und sollte nicht zwischen Teams als Umrechnungstabelle übernommen werden.
Laden Sie die richtigen Personen ein
Die Personen, die voraussichtlich die Arbeit erledigen, sollten abstimmen. Der Product Owner oder Backlog-Verantwortliche erklärt Absicht, Priorität und Kompromisse. Ein Moderator sorgt für einen flüssigen Ablauf, gibt ruhigeren Teilnehmern Raum und verhindert, dass die Diskussion zu einer Verhandlung um eine bevorzugte Zahl wird.
In Agilo benötigen Teilnehmer Konten, um einem Raum beizutreten und abzustimmen. Erstellen Sie den Raum vor der Sitzung, wählen Sie das Schätzungssystem aus, fügen Sie die ersten Punkte hinzu oder importieren Sie sie und teilen Sie die Einladung rechtzeitig, damit alle teilnehmen können.

Aktuelle Agilo-Oberfläche: Acht fiktive Teilnehmer haben abgestimmt, während alle Schätzungen bis zur Aufdeckung verborgen bleiben.
Eine praktische 45-Minuten-Agenda
Nutzen Sie dies als Ausgangspunkt und passen Sie es dann an Anzahl und Komplexität der Punkte an.
| Zeit | Aktivität | Erwünschtes Ergebnis |
|---|---|---|
| 0–5 Min | Skala und Regeln festlegen | Jeder weiß, was die Karten bedeuten und wer abstimmt |
| 5–10 Min | Kalibrierung mit einem vertrauten Punkt | Das Team hat einen gemeinsamen Referenzpunkt |
| 10–38 Min | Schätzen der vorbereiteten Backlog-Punkte | Jeder Punkt wird verstanden, besprochen und erfasst |
| 38–43 Min | Überprüfung ungelöster oder übergroßer Arbeit | Zuständige und nächste Klärungsschritte sind klar |
| 43–45 Min | Sitzung abschließen | Schätzungen und Folgeaufgaben sind dokumentiert |
Fünf gut vorbereitete Punkte sind oft wertvoller als fünfzehn übereilte Abstimmungen. Wenn das Team während der Sitzung wiederholt lange Product Discovery benötigt, verschieben Sie diese Punkte zurück zur Verfeinerung und konzentrieren Sie Planning Poker auf Arbeit, die bereit für eine Größenschätzung ist.
Schritt 1: Kalibrieren mit einem vertrauten Referenzpunkt
Beginnen Sie mit einem kürzlich abgeschlossenen Punkt, dessen Form das Team noch erinnert. Sie schreiben die Geschichte nicht um, um eine perfekte Bewertung zu erzeugen. Sie geben dem Raum einen gemeinsamen Vergleich: „Dieser Punkt hatte eine UI-Änderung, eine API-Änderung und bekannte Testabdeckung; für uns entspricht das einer 3.“
Verwenden Sie nach Möglichkeit Referenzen aus demselben Team und Produktbereich. Eine 5 des Mobile-Teams und eine 5 des Plattform-Teams müssen nicht dasselbe bedeuten.
Für eine konkrete Referenzskala vergleichen Sie diese sechs Beispiele für Story Points, einschließlich der Akzeptanzgrenzen, die einen Punkt kleiner oder größer machen.
Schritt 2: Einen Backlog-Punkt präsentieren
Der Backlog-Verantwortliche erklärt in wenigen Minuten das Ergebnis und die Grenzen. Vermeiden Sie es, eine vorgeschlagene Umsetzung durchzugehen, als sei sie bereits beschlossen. Entwickler sehen möglicherweise einen einfacheren Weg – oder eine Abhängigkeit, die die gesamte Schätzung verändert.
Ein hilfreicher Einstieg klingt so:
Ein angemeldeter Nutzer kann den aktuellen Bericht als CSV exportieren. Diese Runde umfasst die sichtbaren Tabellenfilter, jedoch keine geplanten Exporte oder benutzerdefinierte Spaltenzuordnungen.
Lassen Sie anschließend das Team Fragen stellen. Ändert eine Frage den Umfang, aktualisieren Sie den Punkt vor der Abstimmung.
Schritt 3: Privat abstimmen und gemeinsam aufdecken
Jede schätzende Person wählt eine Karte, ohne die anderen Entscheidungen zu sehen. Verdeckte Stimmen verringern die Verzerrung durch den ersten Wert, die ranghöchste Person oder die Erwartungen des Moderators.
Die Aufdeckung erfolgt erst, wenn alle abgestimmt haben. Agilo kann die Karten je nach Raumeinstellung manuell oder automatisch enthüllen, sobald alle Teilnehmer gewählt haben. Ein Moderator kann auch den Raum-Timer nutzen, wenn das Team eine sanfte Grenze für Fragen oder Abstimmungen benötigt.
Drängen Sie niemanden, der ? gewählt hat. Diese Karte ist ein nützlicher Hinweis: Der Punkt könnte Kontext vermissen, außerhalb der Expertise liegen oder eine Annahme enthalten, die sichtbar gemacht werden sollte.
Schritt 4: Diskutieren Sie die Streuung, nicht jede einzelne Zahl
Wenn die Stimmen sich um benachbarte Werte gruppieren, benötigt das Team möglicherweise nur eine kurze Bestätigung. Ist die Streuung groß – zum Beispiel 3, 3, 5, 8, 13 – beginnen Sie mit den Begründungen für die niedrigen und hohen Schätzungen.
Stellen Sie Fragen wie:
- Was beinhaltet die
13, was die3nicht einschließt? - Gibt es eine Abhängigkeit oder einen Fehlerzustand, den andere übersehen haben?
- Schätzen wir die gleichen Akzeptanzbedingungen?
- Geht eine Person von wiederverwendbarer Infrastruktur aus, die noch nicht existiert?
- Würde eine Aufteilung des Punkts die Hauptunsicherheit beseitigen?
Das Ziel ist ein gemeinsames Verständnis. Eine Einigung kann folgen, doch das Erzwingen derselben Karte für alle, ohne die zugrunde liegenden Differenzen zu klären, untergräbt die Übung.
Wenn eine Person
3und eine andere13wählt: Gute Nachricht – die Karten sind nicht kaputt. Das Team hat genau die Unterhaltung gefunden, für die es gedacht war. 😅

Aktuelle Agilo-Oberfläche nach der Aufdeckung: Die Streuung von 3 bis 8 weist auf unterschiedliche Annahmen hin. Der Durchschnitt von 5,3 ist Kontext, keine automatische endgültige Antwort.
Schritt 5: Klären, aufteilen oder erneut abstimmen
Wählen Sie nach der Diskussion einen von drei Wegen:
- Erneut abstimmen. Der Punkt ist klar, und neue Informationen haben die Sicht des Teams geändert.
- Punkt aufteilen. Die Schätzung ist groß, weil mehrere Ergebnisse oder technische Schritte zusammengefasst wurden.
- Schätzung pausieren. Eine Produktentscheidung, Abhängigkeit oder Untersuchung muss zuerst geklärt werden.
Agilo unterstützt eine weitere Abstimmungsrunde, aber die endgültige Schätzung für das Team wird nicht von Agilo festgelegt. Der Moderator und die Schätzer entscheiden weiterhin, welcher Wert ihre gemeinsame Auffassung widerspiegelt.
Schritt 6: Ergebnis festhalten und weitermachen
Sobald das Team sich auf eine Schätzung geeinigt hat, wird diese beim Backlog-Item vermerkt und das nächste Item ausgewählt, solange die Sitzung noch Schwung hat. Wenn Sie die Agilo Jira-Integration verwenden, können Sie Jira-Issues mit ihrem Kontext importieren und die ausgewählte Schätzung zurückgeben, sobald die Synchronisation konfiguriert ist.
Führen Sie separate Notizen für Folgefragen. Verbergen Sie ungelöste Umfangsfragen nicht hinter einer Zahl, nur um die Liste abzuschließen.
Beispiel: fünf Backlog-Items
Die unten stehenden Werte stammen von einem fiktiven Produktteam, das eigene Referenz-Items verwendet. Sie sind Beispiele für Begründungen, kein allgemeingültiger Antwortschlüssel.
| Backlog-Item | Erste Stimmen | Was das Team entdeckte | Ergebnis |
|---|---|---|---|
| Leeren Zustand zu gespeicherten Suchanfragen hinzufügen | 1, 1, 2, 2, 2 | Text und Design waren bereit; ein zusätzliches Analyse-Ereignis war erforderlich | Einigung auf 2 |
| Gefilterten Bericht als CSV exportieren | 3, 5, 5, 8, 8 | Die API konnte Zeilen streamen, aber Berechtigungen benötigten eine gemeinsame Prüfung | Einigung auf 5 nach Klärung |
| Microsoft-Anmeldung hinzufügen | 3, 5, 8, 13, 13 | Konto-Verknüpfung und Verhalten bei doppelten E-Mails waren unklar | Für eine Produktentscheidung pausiert |
| Benutzern erlauben, Dashboard-Widgets neu anzuordnen | 5, 8, 13, 13, 21 | Desktop-Drag & Drop und mobile Reihenfolge wurden zusammengefasst | In zwei Items aufgeteilt |
| Benachrichtigung anzeigen, wenn ein Import abgeschlossen ist | 2, 2, 3, 3, 5 | Unterschied war, ob Hintergrundjobs bereits ein nutzbares Ereignis lieferten | Einigung auf 3 nach Prüfung des bestehenden Ereignisses |
Betrachten Sie das Widget-Item. Die geringeren Schätzer stellten sich eine reine Desktop-Layout-Änderung vor. Die höheren Schätzer berücksichtigten mobile Gesten, persistente Reihenfolge, Tastaturbedienbarkeit und Migration bestehender Layouts. Kein Mittelwert konnte diese Diskrepanz lösen. Die Aufteilung des Items machte den Umfang explizit und führte zu zwei sinnvolleren Diskussionen.
Häufige Fehler, die die Sitzung schwächen
Das Mittel als Antwort behandeln
Ein Mittelwert kann zwei unvereinbare Interpretationen verbergen. Diskutieren Sie zuerst die Spannweite. Die finale Schätzung sollte die verstandene Arbeit widerspiegeln, nicht arithmetischen Komfort.
Den ranghöchsten Teilnehmer laut abstimmen lassen
Sobald eine Zahl genannt wurde, neigen spätere Schätzungen dazu, sich daran zu orientieren. Halten Sie die Karten bis zur Offenlegung verborgen und fragen Sie nach der unabhängigen Abstimmung nach den Begründungen.
Umsetzung diskutieren, bevor das Ergebnis klar ist
Technische Diskussionen sind wertvoll, jedoch erst, wenn alle verstehen, was das Item erreichen soll. Ansonsten könnte das Team unterschiedliche Produkte schätzen.
Für ein unvorbereitetes Item eine Schätzung erzwingen
„Wir brauchen heute eine Zahl“ beseitigt keine Abhängigkeit. Markieren Sie die Frage, weisen Sie einen Verantwortlichen zu und kehren Sie zurück, wenn die fehlende Entscheidung vorliegt.
Individuen oder Teams anhand von Story Points vergleichen
Punkte sind ein lokales Planungstool. Sie in ein Leistungsziel umzuwandeln, fördert überhöhte Zahlen und macht die Schätzungen weniger nützlich.
Checkliste für Moderatoren
Vor dem Meeting:
- 5–8 kurzfristige Items auswählen;
- Akzeptanzkontext und Links hinzufügen;
- Raum erstellen und Kartensatz auswählen;
- klären, wer Items erklärt und wer abstimmt;
- ein bekanntes Referenz-Item wählen.
Während jeder Runde:
- Stimmen bis zur Offenlegung verborgen halten;
- Begründungen für niedrige und hohe Werte anhören, wenn die Spannweite relevant ist;
- Item aktualisieren, wenn sich Annahmen ändern;
- neu abstimmen, aufteilen oder pausieren statt Erzwungene Einigung;
- ausgewählte Schätzung und Folgeverantwortliche festhalten.
Nach dem Meeting:
- sicherstellen, dass Schätzungen im Backlog sichtbar sind;
- pausierte Items vor dem Sprint Planning klären;
- die Skala nur anpassen, wenn das Team sie dauerhaft als unbrauchbar empfindet.
Workflow in Agilo ausführen
Agilo Planning Poker vereint Backlog-Kontext, private Abstimmung, gleichzeitige Offenlegung, Wiederholungsrunden und die ausgewählte Schätzung in einem Raum. Sie können Arbeit manuell hinzufügen oder Jira-Issues importieren, einen integrierten oder benutzerdefinierten Kartensatz verwenden und direkt zum nächsten Item wechseln, sobald das Team sich einigt.
Erstellen Sie einen Planning Poker-Raum, wenn Ihre Backlog-Items und Teilnehmer bereit sind.
Quellen und weiterführende Literatur
- Agile Alliance: Planning Poker — das grundlegende Muster aus privater Abstimmung, gleichzeitiger Offenlegung, Diskussion und weiteren Runden.
- Der offizielle Scrum Guide — die aktuelle Definition von Scrum und den Verantwortlichkeiten für die Größenbestimmung des Product Backlogs.
