Was vorher fertig sein muss
Für jedes zu schätzende Item liegen Akzeptanzkriterien in Bullet-Form vor, die ein anderes Teammitglied ohne Rückfrage versteht.
Eine gemeinsame Schätzskala (Fibonacci-Werte) mit zwei bis drei kalibrierten Referenzstories ist im Team etabliert.
Was vor Start vorliegen muss
Planning-Poker-Karten (physisch oder Tool wie PlanningPokerOnline, Scrum Poker, Miro-Plugin); Backlog im Ticket-System geöffnet; Timer; Liste der Referenzstories sichtbar; Geräuscharme Umgebung oder ruhiger Call-Channel.
Ein Moderator (Scrum Master oder PO-Stellvertreter); ein Product Owner als Item-Vorsteller; das umsetzende Entwicklungsteam (3-9 Personen); optional ein QA- oder Design-Beteiligter, der mitschätzt.
Backlog-Items sortiert nach Priorität; Akzeptanzkriterien pro Item; Definition of Done; Referenzstories mit gesetzten Punktwerten; bekannte Abhängigkeiten oder Risiken.
2-5 min je Item
Maximale Item-Zahl pro Session festlegen (Erfahrungswert: 6-12 in 60 min). Timeboxen ankündigen: 2 min Klärung, 1 min Schätzung, 3 min Diskussion bei Abweichung. Karten oder Tool für alle bereitstellen.
Die eine Frage, die diese Methode beantwortet
Wie groß ist dieses Item relativ zu unseren Referenzstories, und welche Annahmen oder Risiken treiben Abweichungen in der Gruppe?
Marker: Minute
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
10-2 min: Item vorstellen | 2 min | PO liest Titel, Beschreibung und Akzeptanzkriterien vor. Team stellt klärende Fragen. Keine Lösungsdiskussion, keine Aufgabenzerlegung in dieser Phase. | Wenn nach 2 min noch grundlegende Fragen offen sind, Item zurück ins Refinement. Schätzung ohne geklärten Scope produziert Müll. |
22-3 min: Verdeckt schätzen | 1 min | Jede Person wählt eine Karte verdeckt aus der Fibonacci-Skala. Tools setzen Werte gleichzeitig. Niemand spricht aus, was er schätzt. | Wenn jemand seine Karte vorher zeigt oder kommentiert, Runde verwerfen und neu starten. Anker zerstören die Methode. |
33-4 min: Aufdecken und Spread prüfen | 1 min | Karten gleichzeitig aufdecken. Wenn Spread kleiner als zwei Fibonacci-Stufen (z. B. 3-5): höheren Wert nehmen. Sonst weiter zu Diskussion. | Konsens ist nicht das Ziel, ausreichend Übereinstimmung reicht. Wer auf einem Wert beharrt, blockiert das Refinement. |
44-7 min: Diskussion bei Abweichung | 3 min | Höchster und niedrigster Schätzer erklären ihre Annahmen, ohne Rechtfertigung. Andere ergänzen Risiken oder Annahmen. Danach erneut verdeckt schätzen. | Diskussion strikt timeboxen. Nach maximal zwei Runden parken oder splitten. Endlose Schätzdebatten sind Symptom für unklare Anforderung. |
Was am Ende rauskommt
Aktualisierte Backlog-Items im Ticket-System (Jira, Linear, Azure DevOps) mit Story-Point-Wert, Annahmen im Kommentar, markierten Split-Kandidaten und expliziter Risiko-Notiz bei großen Items.
Schätzwerte werden im Item gehalten. Re-Estimation bei Scope-Änderung im Kommentar-Verlauf dokumentieren, nicht ohne Notiz überschreiben. Annahmen und Risiken bleiben als Item-Kommentar erhalten.
Kompakte Arbeitsvorlage für Planning Poker mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Planning Poker Arbeitsvorlage
## Ziel
Kollaborative Schätzmethode, bei der Teammitglieder verdeckt Karten wählen und Unterschiede diskutieren.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Relative Estimates:
- Assumption Notes:
- Split Candidates:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Refinement — 2026-05-18
**Item: API-Endpoint für Mandanten-Export**
- Akzeptanzkriterien: GET-Endpoint, JSON und CSV, Pagination, Auth via JWT.
- Runde 1: 3, 5, 5, 8, 13. Spread zu groß.
- Diskussion: @anna (3) ging von bestehendem Generator aus. @ben (13) sah Auth-Refactor und neue Pagination-Logik. Annahme geklärt: kein Auth-Refactor nötig, Pagination-Helper existiert.
- Runde 2: 5, 5, 5, 8, 5. Konsens auf 5.
- Annahmen im Item: bestehende Export-Generator-Klasse wiederverwendbar; Pagination-Helper aus Mandanten-Liste übernehmbar.
**Item: Multi-Tenant-Mandantenverwaltung**
- Runde 1: 8, 13, 21, 21, 13. Konsens-Vorschlag 21.
- Markiert für Split: zu groß für einen Sprint. PO schneidet bis Donnerstag in 3 Teilstories.Symptome erkennen, gegensteuern
Eine erfahrene Person nennt eine Zahl vor der Schätzrunde („das ist eine 5“), alle Karten zeigen denselben Wert.
Strikt verdeckt schätzen. Wer vorab eine Zahl nennt, wird höflich unterbrochen. Bei Toolnutzung Funktion zum gleichzeitigen Aufdecken aktivieren.
Statt Annahmen zu klären, beginnt die Gruppe, Implementierung zu skizzieren oder Tasks zu zerlegen.
Moderator unterbricht: „Wir schätzen, wir designen nicht.“ Designfragen ins Refinement oder in Spike-Tickets parken. Schätzung läuft weiter mit aktuellen Annahmen.
Spread liegt bei 8 vs. 21+, auch nach zweiter Runde keine Konvergenz.
Item splitten oder als Spike umwidmen. Keine Schätzung über 13 ohne Split-Versuch. Sehr große Items sind Discovery-Aufgabe, keine Refinement-Aufgabe.
Product Owner gibt eigene Karte ab, oft niedrig („das ist doch einfach“).
Nur das umsetzende Team schätzt. PO klärt Scope und Akzeptanzkriterien. Wenn PO seine Sicht zur Komplexität teilen will, als Annahme dokumentieren, nicht als Schätzwert.
Stakeholder fragt nach Schätzwert und liest ihn als Zusage in Tagen oder Wochen.
Story Points sind relative Komplexität, keine Zeit. Velocity-Daten getrennt halten und für Forecasts mit Range kommunizieren. Schätzwert ohne Kontext nicht herausgeben.
Gruppe schätzt dasselbe Item drei- oder viermal ohne Konvergenz.
Nach maximal zwei Runden Entscheidung erzwingen: höheren Wert nehmen, Item splitten, oder Spike vorschalten. Drei Runden ohne Konvergenz ist Methodenmissbrauch.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.