Meine Session planen

# Session Brief: Story Splitting

## Ziel
Artefakt: Smaller Stories

## Arbeitsfrage
Wie laesst sich die Story in 2-5 Slices teilen, von denen jeder Wert liefert oder Wissen schafft, ohne den Gesamtnutzen zu verlieren?

## Kontext
Story-Entwurf mit Akzeptanzkriterien; bekannte technische Constraints; Definition of Done; Sprint-Kapazitaet als Referenz fuer Slice-Groesse.

## Setup
- Format: Methoden-Session
- Dauer: 20-45 min pro Story
- Modus: Workshop oder async
- Teilnehmende: Ein PO oder Product-naher Rolleninhaber; ein bis zwei Engineers; optional QA; ein Facilitator wenn Team neu im Splitting.
- Owner: Ein PO oder Product-naher Rolleninhaber
- 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 Smaller Stories hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Story-Beschreibung; Whiteboard oder Miro mit Splitting-Patterns als Checkliste (Workflow-Steps, Variations, Data Variants, Operations, Interface, Defer Performance, Defer Quality, Major Effort, Spike); Backlog-Tool fuer neue Stories.

## Vorbereitung
Story sichtbar machen. Splitting-Patterns als Checkliste an die Seite. Regel: jeder Slice liefert eigenstaendigen Wert oder Lernen, kein „Backend-Slice“ ohne Outcome.

## Agenda
1. Phase 1: Story klaeren (5-10 min)
   Owner: Facilitator
   Aktion: Story-Outcome, Akzeptanzkriterien und Definition of Done kurz auffrischen. Hauptnutzen in einem Satz formulieren. Hinweis: Wenn das Outcome nicht in einem Satz formulierbar ist, sind mehrere Outcomes vermischt. Splitting beginnt schon hier mit Outcome-Trennung. 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: Smaller Stories

2. Phase 2: Splitting-Pattern waehlen (10 min)
   Owner: Facilitator
   Aktion: Patterns durchgehen (Workflow-Steps, Variations, Data Variants, Operations, Interface, Defer Performance, Defer Quality, Major Effort, Spike). Mehrere Patterns moeglich, das passendste auswaehlen. Hinweis: Workflow-Steps und Variations sind haeufigste Patterns. Wenn keine passt, Story ist evtl. Spike oder neu zu schneiden. 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: Acceptance Criteria

3. Phase 3: Slices erzeugen (15-20 min)
   Owner: Facilitator
   Aktion: Slices als eigene Stories formulieren. Jeder Slice hat Outcome, Akzeptanzkriterien, Sub-Definition of Done. Reihenfolge nach Wert-Lern-Mix priorisieren. Hinweis: Slices sollten unabhaengig deploybar sein. Wenn ein Slice nur als Paket mit anderen Wert liefert, ist die Trennung zu technisch. 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 Rationale

4. Phase 4: Schaetzung und Backlog (10-15 min)
   Owner: Owner
   Aktion: Slices schaetzen (Story Points, T-Shirt, Stundengrobschaetzung). Original-Story als Parent oder Epic schliessen. Slices ins Backlog mit Reihenfolge. Hinweis: Wenn jeder Slice gleich gross ist wie die Original-Story, war das Splitting nicht erfolgreich. Maximalgrenze pro Slice harten Sprint-Anteil. 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: Smaller Stories

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: Smaller Stories

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

# Smaller Stories: Story Splitting

## Arbeitsfrage
Wie laesst sich die Story in 2-5 Slices teilen, von denen jeder Wert liefert oder Wissen schafft, ohne den Gesamtnutzen zu verlieren?

## Kontext
Story-Entwurf mit Akzeptanzkriterien; bekannte technische Constraints; Definition of Done; Sprint-Kapazitaet als Referenz fuer Slice-Groesse.

## Beteiligte
- Owner: Ein PO oder Product-naher Rolleninhaber
- Teilnehmende: Ein PO oder Product-naher Rolleninhaber; ein bis zwei Engineers; optional QA; ein Facilitator wenn Team neu im Splitting.

## Input
Story-Beschreibung; Whiteboard oder Miro mit Splitting-Patterns als Checkliste (Workflow-Steps, Variations, Data Variants, Operations, Interface, Defer Performance, Defer Quality, Major Effort, Spike); Backlog-Tool fuer neue Stories.

## Vorlage
# Story Splitting Checklist

- [ ] Ziel und Kontext geklärt
- [ ] Input-Material gesammelt
- [ ] Beteiligte und Rollen benannt
- [ ] Durchführung nach Run Sheet vorbereitet
- [ ] Ergebnisartefakte erstellt
- [ ] Smaller Stories aktualisiert
- [ ] Acceptance Criteria aktualisiert
- [ ] Split Rationale aktualisiert
- [ ] Offene Fragen dokumentiert
- [ ] Nächster Schritt mit Owner und Datum gesetzt

## Fertigstellungscheck
- Smaller Stories 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