Meine Session planen

# Session Brief: Planning Poker

## Ziel
Artefakt: Relative Estimates

## Arbeitsfrage
Wie groß ist dieses Item relativ zu unseren Referenzstories, und welche Annahmen oder Risiken treiben Abweichungen in der Gruppe?

## Kontext
Backlog-Items sortiert nach Priorität; Akzeptanzkriterien pro Item; Definition of Done; Referenzstories mit gesetzten Punktwerten; bekannte Abhängigkeiten oder Risiken.

## Setup
- Format: Methoden-Session
- Dauer: 2-5 min je Item
- Modus: Workshop oder async
- Teilnehmende: 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.
- Owner: Ein Moderator (Scrum Master oder PO-Stellvertreter)
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Relative Estimates hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
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.

## Vorbereitung
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.

## Agenda
1. 0-2 min: Item vorstellen (2 min)
   Owner: Facilitator
   Aktion: PO liest Titel, Beschreibung und Akzeptanzkriterien vor. Team stellt klärende Fragen. Keine Lösungsdiskussion, keine Aufgabenzerlegung in dieser Phase. Hinweis: Wenn nach 2 min noch grundlegende Fragen offen sind, Item zurück ins Refinement. Schätzung ohne geklärten Scope produziert Müll. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Relative Estimates

2. 2-3 min: Verdeckt schätzen (1 min)
   Owner: Facilitator
   Aktion: Jede Person wählt eine Karte verdeckt aus der Fibonacci-Skala. Tools setzen Werte gleichzeitig. Niemand spricht aus, was er schätzt. Hinweis: Wenn jemand seine Karte vorher zeigt oder kommentiert, Runde verwerfen und neu starten. Anker zerstören die Methode. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Assumption Notes

3. 3-4 min: Aufdecken und Spread prüfen (1 min)
   Owner: Facilitator
   Aktion: Karten gleichzeitig aufdecken. Wenn Spread kleiner als zwei Fibonacci-Stufen (z. B. 3-5): höheren Wert nehmen. Sonst weiter zu Diskussion. Hinweis: Konsens ist nicht das Ziel, ausreichend Übereinstimmung reicht. Wer auf einem Wert beharrt, blockiert das Refinement. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Split Candidates

4. 4-7 min: Diskussion bei Abweichung (3 min)
   Owner: Owner
   Aktion: Höchster und niedrigster Schätzer erklären ihre Annahmen, ohne Rechtfertigung. Andere ergänzen Risiken oder Annahmen. Danach erneut verdeckt schätzen. Hinweis: Diskussion strikt timeboxen. Nach maximal zwei Runden parken oder splitten. Endlose Schätzdebatten sind Symptom für unklare Anforderung. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Relative Estimates

5. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Relative Estimates

## Abschluss
- Ergebnisartefakt aktualisieren: Relative Estimates
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Relative Estimates: Planning Poker

## Arbeitsfrage
Wie groß ist dieses Item relativ zu unseren Referenzstories, und welche Annahmen oder Risiken treiben Abweichungen in der Gruppe?

## Kontext
Backlog-Items sortiert nach Priorität; Akzeptanzkriterien pro Item; Definition of Done; Referenzstories mit gesetzten Punktwerten; bekannte Abhängigkeiten oder Risiken.

## Beteiligte
- Owner: Ein Moderator (Scrum Master oder PO-Stellvertreter)
- Teilnehmende: 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.

## Input
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.

## Vorlage
# 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.

## Fertigstellungscheck
- Relative Estimates ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren