User Story Splitting

User Story Splitting ist der Prozess, große, komplexe User Stories in kleinere, handhabbare Stories zu zerlegen, die dennoch Wert für den Nutzer liefern. Gutes Splitting ermöglicht es Teams, schneller zu lernen, früher Wert zu liefern und Risiken zu reduzieren.

💡 Warum Splitting wichtig ist

Durch das Splitting von User Stories wollen wir schon früher erste vereinfachte Lösungen schaffen, aus denen wir lernen können. Das Ziel ist nicht perfekte Planung im Voraus, sondern iteratives Lernen durch schrittweise Lieferung.

Wann sollte man Stories splitten?

Stories sollten gesplittet werden, wenn sie:

Zu groß für einen Sprint sind: Eine Story sollte in einem Sprint fertigstellbar sein
Zu viel Unsicherheit enthalten: Hohe Komplexität oder unklare Anforderungen
Verschiedene Wertbeiträge mischen: Mehrere unabhängige Features in einer Story
Technische und fachliche Aspekte vermischen: Backend, Frontend und Business-Logik getrennt lieferbar

INVEST-Kriterien für gute User Stories

Eine gut gesplittete Story erfüllt die INVEST-Kriterien:

I
Independent (Unabhängig): Kann unabhängig von anderen Stories entwickelt werden
N
Negotiable (Verhandelbar): Details können während der Entwicklung verfeinert werden
V
Valuable (Wertvoll): Liefert messbaren Wert für den Nutzer oder das Business
E
Estimable (Schätzbar): Das Team kann den Aufwand grob einschätzen
S
Small (Klein): Kann in einem Sprint fertiggestellt werden
T
Testable (Testbar): Klare Akzeptanzkriterien ermöglichen Tests

Bewährte Splitting-Patterns

Es gibt verschiedene bewährte Muster, um User Stories zu splitten:

1. Workflow-Steps (Schritte im Ablauf)

Teile die Story entlang der Schritte im User-Workflow auf.

Beispiel: "Als Nutzer kann ich ein Produkt kaufen"

→ Story 1: Produkt in Warenkorb legen
→ Story 2: Adresse eingeben
→ Story 3: Bezahlen
→ Story 4: Bestellbestätigung erhalten

2. Business Rules (Geschäftsregeln)

Splitte nach verschiedenen Geschäftsregeln oder Variationen.

Beispiel: "Als Admin kann ich Rabatte vergeben"

→ Story 1: Prozentualer Rabatt
→ Story 2: Fester Betrag
→ Story 3: Buy-One-Get-One-Free
→ Story 4: Staffelrabatte

3. Simple / Complex (Einfach zuerst)

Beginne mit der einfachsten Version, füge später Komplexität hinzu.

Beispiel: "Als Nutzer kann ich Dateien hochladen"

→ Story 1: Einzelne kleine Dateien (bis 5MB)
→ Story 2: Größere Dateien (bis 100MB)
→ Story 3: Multiple Dateien gleichzeitig
→ Story 4: Drag & Drop Support

4. CRUD Operations (Datenbankoperationen)

Splitte nach Create, Read, Update, Delete Operationen.

Beispiel: "Als Admin kann ich Produkte verwalten"

→ Story 1: Produkt anlegen (Create)
→ Story 2: Produkte anzeigen (Read)
→ Story 3: Produkt bearbeiten (Update)
→ Story 4: Produkt löschen (Delete)

5. Data Variations (Datenvarianten)

Teile nach verschiedenen Datentypen oder -formaten auf.

Beispiel: "Als Nutzer kann ich Inhalte importieren"

→ Story 1: CSV-Import
→ Story 2: Excel-Import
→ Story 3: JSON-Import
→ Story 4: XML-Import

6. Interface Variations (Schnittstellen)

Splitte nach verschiedenen Zugangswegen oder Devices.

Beispiel: "Als Nutzer kann ich mich authentifizieren"

→ Story 1: Login via E-Mail/Passwort
→ Story 2: Social Login (Google)
→ Story 3: SSO (Single Sign-On)
→ Story 4: Zwei-Faktor-Authentifizierung

Häufige Fehler beim Splitting

✗Technisches Splitting: "Frontend implementieren" + "Backend implementieren" liefert keinen End-to-End-Wert
✗Zu kleinteilig: Stories werden so klein, dass der Overhead (Planning, Review, etc.) den Nutzen übersteigt
✗Architektur-Tasks: "Datenbank-Schema erstellen" ist keine User Story mit Wert
✗Keine vertikalen Slices: Stories müssen durch alle Schichten (UI, Logic, Data) gehen
✗Details im Voraus festlegen: Splitting ist kein Wasserfallansatz - Details werden im Sprint geklärt

Best Practices

✓Früh schätzen: Lass das Team große Stories früh schätzen, um Unsicherheiten zu identifizieren
✓Vertikale Slices: Jede Story sollte durch alle technischen Schichten gehen und testbar sein
✓Einfachste Lösung zuerst: Starte mit der simpelsten Version, lerne daraus, iteriere
✓Gemeinsam splitten: Product Owner, Team und ggf. Stakeholder gemeinsam
✓INVEST-Check: Prüfe gesplittete Stories gegen INVEST-Kriterien
✓Wert im Fokus: Jede Story muss für sich genommen Wert liefern

Der Splitting-Prozess

1. Story vorstellen: Product Owner erklärt die große Story und deren Wert
2. Komplexität erkennen: Team schätzt grob und identifiziert Unsicherheiten, Risiken und Aufwand
3. Splitting-Pattern wählen: Wählt ein passendes Pattern (Workflow, Business Rules, etc.)
4. Stories formulieren: Formuliert kleinere Stories mit klarem Wert
5. INVEST-Check: Prüft jede gesplittete Story gegen INVEST-Kriterien
6. Priorisieren: Product Owner priorisiert die neuen Stories basierend auf Wert und Lernen

Zusammenfassung

User Story Splitting ist eine Kunst, keine Wissenschaft. Es gibt keine perfekte Lösung, sondern verschiedene Möglichkeiten, die je nach Kontext sinnvoller sind.

Das Ziel ist nicht, im Voraus alles perfekt zu planen, sondern früh zu liefern, zu lernen und zu iterieren. Jede gesplittete Story sollte testbaren Wert liefern und das Team näher an die Produktvision bringen.

← Zurück zur Scrum-Übersicht Product Backlog →Product Owner Training

Scrum Guide