Meine Session planen

# Session Brief: Story Points

## Ziel
Artefakt: Point Estimates

## Arbeitsfrage
Wie groß ist dieses Item relativ zu unseren Referenzstories unter Berücksichtigung von Umfang, Komplexität, Risiko und Unsicherheit?

## Kontext
Referenzstories aus realer Liefer-Historie mit gesetzten Punkten; gemeinsame Skala-Definition (z. B. „1 = trivial, 13 = größer Story unter Splitting-Verdacht“); Definition of Done.

## Setup
- Format: Methoden-Session
- Dauer: 1-5 min je Item, typisch 60-90 min für Refinement-Session
- Modus: Workshop oder async
- Teilnehmende: Ein Moderator (Scrum Master oder Tech Lead); ein Product Owner für Scope; das umsetzende Team (3-9 Personen); ein Scribe für Annahmen, falls nötig.
- Owner: Ein Moderator (Scrum Master oder Tech Lead)
- 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 Point Estimates hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Schätz-Tool (Planning Poker, Miro, Linear/Jira mit Story-Point-Feld); Referenzstory-Liste sichtbar; Skala-Plakat (typisch Fibonacci 1, 2, 3, 5, 8, 13, 20); Backlog-Items mit Beschreibung und Kriterien.

## Vorbereitung
Referenzstories als Anker an Wand oder Board sichtbar (z. B. „3 = SSO Google, 5 = API-Endpoint Mandanten-Export, 8 = Self-Service-Portal-Teil“). Skala-Plakat. Regel ansagen: Punkte umfassen Umfang, Komplexität, Risiko und Unsicherheit, nicht nur Zeit.

## Agenda
1. Phase 1: Referenzstories kalibrieren (10 min)
   Owner: Facilitator
   Aktion: Referenzstories pro Punktwert durchgehen. Team bestätigt oder korrigiert. Neue Teammitglieder erhalten Erklärung pro Wert. Hinweis: Ohne Kalibrierung sind Punkte teamintern bedeutungslos. Bei Teamwechsel (>30% neu) Referenzen neu setzen, nicht alte beibehalten. 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: Point Estimates

2. Phase 2: Item-Schätzung (2-5 min je Item)
   Owner: Facilitator
   Aktion: Item vorstellen, Fragen klären, Schätzung (Planning Poker oder direkt). Punkte beziehen sich auf relative Größe gegenüber Referenz, nicht auf Stunden. Hinweis: Wenn jemand fragt „wie viele Stunden sind das?“, Methode wurde nicht verstanden. Geduldig erklären: Punkte sind relative Komplexitätseinheit, Velocity macht später Forecasting möglich. 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: Reference Stories

3. Phase 3: Große Items splitten (5-10 min je Item)
   Owner: Facilitator
   Aktion: Items mit 13+ Punkten als Splitting-Kandidaten markieren. Pro Item Vorschlag mit Owner und Frist. Items über 20 Punkte ohne Split gehen nicht in Sprint. Hinweis: Große Punkte sind nicht falsch, aber riskant. Splitting reduziert Unsicherheit und erlaubt feinere Velocity-Vorhersage. Wer nicht splitten kann, hat unklares Lösungsverständnis. 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: Velocity Data

4. Phase 4: Velocity-Auswertung (10 min)
   Owner: Owner
   Aktion: Nach Sprint-Ende erledigte Punkte pro Sprint dokumentieren. Velocity der letzten 3-5 Sprints als Range (z. B. „22-31 Points/Sprint“). Forecasting mit dieser Range, nicht mit Mittelwert. Hinweis: Velocity ist teamintern. Niemals zur Team-Vergleichung nutzen, sonst werden Punkte inflationiert. Velocity-Trend bei Teamwechsel oder Tech-Migration neu kalibrieren. 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: Point 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: Point Estimates

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

# Point Estimates: Story Points

## Arbeitsfrage
Wie groß ist dieses Item relativ zu unseren Referenzstories unter Berücksichtigung von Umfang, Komplexität, Risiko und Unsicherheit?

## Kontext
Referenzstories aus realer Liefer-Historie mit gesetzten Punkten; gemeinsame Skala-Definition (z. B. „1 = trivial, 13 = größer Story unter Splitting-Verdacht“); Definition of Done.

## Beteiligte
- Owner: Ein Moderator (Scrum Master oder Tech Lead)
- Teilnehmende: Ein Moderator (Scrum Master oder Tech Lead); ein Product Owner für Scope; das umsetzende Team (3-9 Personen); ein Scribe für Annahmen, falls nötig.

## Input
Schätz-Tool (Planning Poker, Miro, Linear/Jira mit Story-Point-Feld); Referenzstory-Liste sichtbar; Skala-Plakat (typisch Fibonacci 1, 2, 3, 5, 8, 13, 20); Backlog-Items mit Beschreibung und Kriterien.

## Vorlage
# Story Points Arbeitsvorlage

## Ziel

Relative Einheit zur Schätzung von Umfang, Komplexität, Risiko und Unsicherheit von Backlog Items.

## 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
- Point Estimates:
- Reference Stories:
- Velocity Data:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

## Fertigstellungscheck
- Point 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