Was vorher fertig sein muss
Eine User Story laesst sich nicht innerhalb eines Sprints abschliessen oder uebersteigt vereinbarte Schaetzschwellen (z. B. >8 Story Points).
Das Big Picture der Story im Kontext ist bekannt, sodass Slices ihren Bezug zur Journey behalten.
Was vor Start vorliegen muss
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.
Ein PO oder Product-naher Rolleninhaber; ein bis zwei Engineers; optional QA; ein Facilitator wenn Team neu im Splitting.
Story-Entwurf mit Akzeptanzkriterien; bekannte technische Constraints; Definition of Done; Sprint-Kapazitaet als Referenz fuer Slice-Groesse.
20-45 min pro Story
Story sichtbar machen. Splitting-Patterns als Checkliste an die Seite. Regel: jeder Slice liefert eigenstaendigen Wert oder Lernen, kein „Backend-Slice“ ohne Outcome.
Die eine Frage, die diese Methode beantwortet
Wie laesst sich die Story in 2-5 Slices teilen, von denen jeder Wert liefert oder Wissen schafft, ohne den Gesamtnutzen zu verlieren?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Story klaeren | 5-10 min | Story-Outcome, Akzeptanzkriterien und Definition of Done kurz auffrischen. Hauptnutzen in einem Satz formulieren. | Wenn das Outcome nicht in einem Satz formulierbar ist, sind mehrere Outcomes vermischt. Splitting beginnt schon hier mit Outcome-Trennung. |
2Phase 2: Splitting-Pattern waehlen | 10 min | Patterns durchgehen (Workflow-Steps, Variations, Data Variants, Operations, Interface, Defer Performance, Defer Quality, Major Effort, Spike). Mehrere Patterns moeglich, das passendste auswaehlen. | Workflow-Steps und Variations sind haeufigste Patterns. Wenn keine passt, Story ist evtl. Spike oder neu zu schneiden. |
3Phase 3: Slices erzeugen | 15-20 min | Slices als eigene Stories formulieren. Jeder Slice hat Outcome, Akzeptanzkriterien, Sub-Definition of Done. Reihenfolge nach Wert-Lern-Mix priorisieren. | Slices sollten unabhaengig deploybar sein. Wenn ein Slice nur als Paket mit anderen Wert liefert, ist die Trennung zu technisch. |
4Phase 4: Schaetzung und Backlog | 10-15 min | Slices schaetzen (Story Points, T-Shirt, Stundengrobschaetzung). Original-Story als Parent oder Epic schliessen. Slices ins Backlog mit Reihenfolge. | Wenn jeder Slice gleich gross ist wie die Original-Story, war das Splitting nicht erfolgreich. Maximalgrenze pro Slice harten Sprint-Anteil. |
Was am Ende rauskommt
Liste neuer Stories im Backlog mit Outcome, Akzeptanzkriterien, Schaetzung und Reihenfolge; Original-Story als Epic oder geschlossen. Splitting-Notiz als Kommentar mit angewandtem Pattern und Begruendung.
Splitting-Entscheidung als Kommentar im Backlog-Tool: angewandtes Pattern, Datum, Beteiligte. Bei Slice-Aenderungen Verweis auf Parent erhalten.
Kompakte Arbeitsvorlage für Story Splitting mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# 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 gesetztKonkret gefülltes Szenario
## Story Splitting - WS-1303 „Self-Service Onboarding fuer Solo-Selbststaendige“
**Original-Story**: 21 Story Points, zu gross fuer einen Sprint.
**Outcome**: Solo-Selbststaendige aktivieren ihr Konto in unter 5 min ohne Customer-Success-Kontakt.
**Pattern**: Workflow-Steps plus Variations.
**Slices**
- WS-1303-01 (5 Pkt): Registrierung mit E-Mail und Use-Case-Wahl. Outcome: Nutzer ist registriert und Use Case ist erfasst. Independent deploybar.
- WS-1303-02 (5 Pkt): Use-Case-spezifische Onboarding-Sequenz (3 Schritte). Outcome: Nutzer kennt die wichtigsten Funktionen.
- WS-1303-03 (3 Pkt): Erste Buchung als geleiteter Flow (Tutorial-Overlay). Outcome: Nutzer hat erste Buchung versucht.
- WS-1303-04 (5 Pkt): Activation-Tracking und Alert. Outcome: Customer Success sieht Nutzer mit Aktivierungs-Stau.
- WS-1303-05 (3 Pkt): Welcome-Mail-Sequenz mit Use-Case-Inhalt. Outcome: Nutzer erhaelt 3 personalisierte Mails ueber 7 Tage.
**Reihenfolge**: 01 -> 02 -> 03 -> 05 -> 04 (04 nach Daten verfuegbar).
**Notiz**: Original-Story WS-1303 als Epic geschlossen. Pattern Workflow-Steps gewaehlt, weil Onboarding eine klare Stufenfolge ist. Variations spaeter moeglich (z. B. Team statt Solo).Symptome erkennen, gegensteuern
Slices heissen „Backend“, „API“, „Frontend“, jeder ohne eigenstaendigen Wert.
Vertikales Slicing: jeder Slice liefert von Frontend bis Datenbank ein Stueck nutzbaren Wert. Wenn Backend-only noetig, ist es ein Spike oder Technical Story, nicht Slice.
Jeder Slice ist noch immer 8+ Punkte, Sprint-Risiko nicht reduziert.
Splitting wiederholen. Wenn Pattern nicht weiter zerlegt, anderes Pattern probieren. Mehrere Patterns kombinierbar.
Nutzer hat erst nach Slice 4 von 5 einen sichtbaren Mehrwert.
Pro Slice fragen: was kann der Nutzer nach diesem Slice mehr als vorher. Wenn nichts, Slice neu schneiden.
Slices wiederholen identische Akzeptanzkriterien, Unterschiede unklar.
Pro Slice eigene, spezifische Kriterien. Doppelung entfernen. Wenn Kriterien identisch, Slice ist redundant.
Ein Slice ist eigentlich technische Recherche ohne Outcome.
Spike explizit als Spike kennzeichnen, mit Zeitbox und klarem Lernziel. Nicht als Wert-Slice taeuschen.
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.