So teilen Sie Epics in sprint-fertige Stories auf

Agiles Team an einem Whiteboard, das einen grossen Haftzettel in mehrere kleinere aufteilt und so den Prozess der Zerlegung eines Epics in handhabbare User Stories darstelltAgiles Team an einem Whiteboard, das einen grossen Haftzettel in mehrere kleinere aufteilt und so den Prozess der Zerlegung eines Epics in handhabbare User Stories darstellt Ein Epic in Ihrem Backlog ist keine Arbeit. Es ist ein Versprechen, dass irgendwo darin Arbeit steckt. Solange Sie es nicht in Stories zerlegt haben, die Ihr Team schätzen und in einem einzelnen Sprint liefern kann, ist es nur ein Platzhalter mit Ambitionen. Die meisten Teams wissen das. Wo sie ins Stocken geraten, ist die eigentliche Aufteilung. Das Epic fühlt sich wie ein grosses Ganzes an, und jeder Versuch, es aufzuteilen, produziert entweder Teile, die zu klein sind, um sinnvoll zu sein, oder zu gross, um in einen Sprint zu passen. Dieser Leitfaden behandelt die Muster und Techniken, die den Schnitt sauber machen.

Was eine Story "sprint-fertig" macht

Eine sprint-fertige Story erfüllt diese Kriterien:
  • Klein genug, um in einem Sprint abgeschlossen zu werden (idealerweise 1-5 Story Points)
  • Unabhängig lieferbar, das heisst, sie hängt nicht davon ab, dass andere Stories zuerst fertig werden
  • Vertikal geschnitten, d. h. sie liefert einen dünnen Querschnitt der End-to-End-Funktionalität, nicht nur ein Backend-Teil oder nur eine Benutzeroberfläche
  • Schätzbar durch Ihr Team im Planning Poker, ohne eine 15-minütige Debatte
  • Testbar mit einer klaren Bestanden/Nicht-Bestanden-Bedingung
Wenn Sie mit den INVEST-Kriterien vertraut sind, ist es dasselbe Prinzip. Das Ziel sind Stories, die konkret genug sind, um daraus zu entwickeln.

6 Muster zum Aufteilen von Epics

Es gibt nicht den einen richtigen Weg, ein Epic aufzuteilen. Aber diese sechs Muster decken die meisten Situationen ab. Probieren Sie sie der Reihe nach durch. Das erste, das passt, liefert in der Regel die saubersten Stories.

1. Aufteilen nach Workflow-Schritt

Die meisten Epics beschreiben einen mehrstufigen Prozess. Jeder Schritt kann zu einer eigenen Story werden. Epic: "Als Kunde möchte ich ein Produkt online kaufen."
StoryBeschreibung
Produkte durchstöbernKunde kann einen Produktkatalog mit Filteroptionen anzeigen
In den Warenkorb legenKunde kann Artikel in einen Warenkorb legen
Zur Kasse gehenKunde kann Versand- und Zahlungsdaten eingeben
BestellbestätigungKunde erhält nach dem Kauf eine Bestätigungs-E-Mail
Jede Story ist für sich wertvoll. Ein Kunde, der Produkte durchstöbern kann, erhält einen Mehrwert, noch bevor die Kasse existiert.

2. Aufteilen nach Geschäftsregel

Wenn ein Epic Verzweigungslogik oder mehrere Regeln enthält, ist jede Regel ein natürlicher Trennpunkt. Epic: "Als Benutzer möchte ich, dass das System die Versandkosten berechnet."
  • Kostenloser Versand für Bestellungen über 50 $
  • Pauschal 5 $ für Standard-Inlandsversand
  • Echtzeit-Spediteurstarife für Expressversand
  • Internationaler Versand mit Zollkostenschätzung
Beginnen Sie mit der einfachsten Regel (Pauschale) und fügen Sie in nachfolgenden Sprints Komplexität hinzu.

3. Aufteilen nach Benutzertyp

Wenn verschiedene Benutzer auf unterschiedliche Weise mit derselben Funktion interagieren, ist jede Perspektive eine Story. Epic: "Als Benutzer möchte ich Teammitglieder verwalten."
  • Als Admin möchte ich neue Mitglieder per E-Mail einladen
  • Als Admin möchte ich Mitglieder aus dem Team entfernen
  • Als Mitglied möchte ich sehen, wer in meinem Team ist
  • Als Eigentümer möchte ich die Inhaberschaft an einen anderen Admin übertragen

4. Aufteilen nach Happy Path vs. Grenzfälle

Bauen Sie zuerst den Standardfall. Behandeln Sie Fehler, Grenzfälle und Validierung in Folge-Stories. Epic: "Als Benutzer möchte ich Profilfotos hochladen."
  • Happy Path: Ein JPEG oder PNG unter 5 MB hochladen und es als Avatar anzeigen
  • Grenzfall: Fehlermeldung anzeigen, wenn die Datei zu gross oder das Format falsch ist
  • Grenzfall: Das Bild vor dem Speichern zuschneiden und in der Grösse anpassen
  • Grenzfall: Ein vorhandenes Foto löschen oder ersetzen
Entwickler betrachtet ein Whiteboard-Diagramm, das eine grosse Box mit der Beschriftung Epic zeigt, die in kleinere verbundene Boxen aufgeteilt wird, die User Stories darstellen, mit Pfeilen, die Abhängigkeiten zeigenEntwickler betrachtet ein Whiteboard-Diagramm, das eine grosse Box mit der Beschriftung Epic zeigt, die in kleinere verbundene Boxen aufgeteilt wird, die User Stories darstellen, mit Pfeilen, die Abhängigkeiten zeigen

5. Aufteilen nach Datentyp oder Plattform

Wenn eine Funktion auf mehrere Datentypen, Plattformen oder Integrationen zutrifft, ist jede davon eine Story. Epic: "Als Benutzer möchte ich meine Berichte exportieren."
  • Export als CSV
  • Export als PDF
  • Export als Excel
  • Geplanten Export per E-Mail versenden

6. Aufteilen nach Leistung oder Skalierung

Beginnen Sie mit etwas, das für den häufigsten Fall funktioniert. Optimieren Sie später. Epic: "Als Benutzer möchte ich projektübergreifend suchen."
  • Suche innerhalb des aktuellen Projekts (einfache Abfrage)
  • Suche über alle Projekte hinweg (erfordert Indexierung)
  • Filter hinzufügen (Zeitraum, Zuständiger, Status)
  • Autovervollständigung während der Eingabe

Ein konkretes Beispiel: "Benutzerbenachrichtigungen" aufteilen

So sieht das in der Praxis aus. Angenommen, Ihr Backlog enthält dieses Epic: "Als Benutzer möchte ich Benachrichtigungen über für mich relevante Aktivitäten erhalten." Das ist riesig. Wenden wir die Muster an: Zuerst nach Workflow aufteilen. Senden, Empfangen und Verwalten von Benachrichtigungen sind separate Anliegen. Dann nach Kanal aufteilen. E-Mail, In-App und Push-Benachrichtigungen sind jeweils eine eigene Story. Innerhalb jedes Kanals nach Geschäftsregel aufteilen. Welche Ereignisse lösen eine Benachrichtigung aus? Jedes einzelne (in einem Kommentar erwähnt, eine Aufgabe zugewiesen, Frist nähert sich) ist eine Story. Schliesslich den Happy Path wählen. Beginnen Sie mit "Benutzer erhält eine In-App-Benachrichtigung, wenn ihm eine Aufgabe zugewiesen wird." Ein Kanal, ein Auslöser, fertig. E-Mail, Push, Einstellungen und Zusammenfassungsoptionen kommen später hinzu. Das Ergebnis: Anstatt eines Epics, das auf "riesig" geschätzt wird und drei Sprints im Backlog liegt, erhalten Sie 8-12 Stories, die priorisiert, geschätzt und schrittweise geliefert werden können.

Die Regel des vertikalen Schnitts

Der häufigste Fehler beim Aufteilen ist, ein Epic nach technischer Schicht zu zerlegen: Schneiden Sie stattdessen vertikal. Jede Story sollte alle Schichten berühren, die nötig sind, um ein dünnes Stück funktionierender Funktionalität zu liefern, das jemand tatsächlich nutzen und testen kann. Ein vertikaler Schnitt für eine Benachrichtigungsfunktion könnte lauten: "Wenn einem Benutzer eine Aufgabe zugewiesen wird, erscheint eine In-App-Benachrichtigung." Das berührt das Backend (Ereignisauslöser, Benachrichtigungsdatensatz), die API (Endpunkt zum Abrufen von Benachrichtigungen) und das Frontend (Benachrichtigungs-Badge und -Liste). Es ist dünn, aber es funktioniert end-to-end. Diagramm, das den Unterschied zwischen horizontaler Aufteilung nach technischer Schicht und vertikaler Aufteilung nach benutzerseitiger Funktionalität zeigt, wobei der vertikale Ansatz als korrekte Methode hervorgehoben istDiagramm, das den Unterschied zwischen horizontaler Aufteilung nach technischer Schicht und vertikaler Aufteilung nach benutzerseitiger Funktionalität zeigt, wobei der vertikale Ansatz als korrekte Methode hervorgehoben ist

Wenn Stories immer noch zu gross sind

Manchmal teilen Sie ein Epic auf und die resultierenden Stories sind immer noch zu gross. Einige Anzeichen:
  • Das Team schätzt sie auf 13+ Punkte
  • Sie hat mehr als 5 Akzeptanzkriterien
  • Die Beschreibung verwendet das Wort "und", um zwei verschiedene Verhaltensweisen zu verbinden
  • Mehrere Teammitglieder müssten gleichzeitig daran arbeiten
Wenn das passiert, wenden Sie dieselben Muster erneut an. Eine Story über "Benutzer kann mit Versand und Zahlung zur Kasse gehen" wird aufgeteilt in "Benutzer kann Lieferadresse eingeben" und "Benutzer kann Zahlungsdaten eingeben." Machen Sie weiter, bis jedes Teil bequem in einen Sprint passt.

Tools nutzen, um die Aufteilung zu beschleunigen

Das Aufteilen von Epics ist eine Fähigkeit, die sich mit der Übung verbessert, aber Tools können den Prozess beschleunigen. Kollabes Story Splitter nimmt eine Epic-Beschreibung und generiert sprint-fertige Stories anhand der oben beschriebenen Muster. Es ist ein guter Ausgangspunkt, wenn Sie vor einem grossen Epic stehen und nicht wissen, wo Sie den Schnitt setzen sollen. Sobald Sie Ihre Stories haben, kann der User Story Generator dabei helfen, sie mit passenden Akzeptanzkriterien und dem Standard-User-Story-Format auszuarbeiten. Bringen Sie sie dann ins Planning Poker, um zu schätzen und zu überprüfen, ob die Aufteilung für Ihr Team tatsächlich Sinn ergibt.

Eine kurze Checkliste vor dem Sprint Planning

Gehen Sie diese Liste durch, bevor Sie aufgeteilte Stories in einen Sprint aufnehmen:

Jede Story liefert einen Mehrwert, den ein Benutzer sehen oder mit dem er interagieren kann

Keine Story hängt von einer anderen unerledigten Story im selben Sprint ab

Das Team kann jede Story ohne langwierige Debatte schätzen

Akzeptanzkriterien sind für jede Story definiert

Stories sind vertikal geschnitten, nicht nach technischer Schicht aufgeteilt

Der gesamte Umfang des ursprünglichen Epics wird über alle Stories hinweg abgedeckt

Wenn alle sechs Punkte erfüllt sind, sind Ihre Stories bereit für das Sprint Planning.

Fangen Sie an aufzuteilen

Sechs Muster, eine Regel: Jede Story sollte einen vertikalen Schnitt von Mehrwert liefern, der in einen Sprint passt. Wenn Sie ratlos vor einem vagen Epic stehen, wählen Sie das erste passende Muster, setzen Sie den Schnitt und validieren Sie mit einer Schätzung. Wenn die Schätzungen immer noch weit auseinanderliegen, schneiden Sie erneut.

Klein genug, um in einem Sprint fertig zu werden, idealerweise auf 1-5 Story Points geschätzt. Wenn Ihr Team Stories regelmässig in 1-3 Tagen abschliesst, sind Sie auf einem guten Weg. Stories, die den gesamten Sprint in Anspruch nehmen, sind riskant, weil kein Spielraum für Überraschungen bleibt.

Das ist in Ordnung. Ein Epic mit 15-20 Stories bedeutet einfach, dass Sie eine klare Roadmap für die Lieferung haben. Priorisieren Sie konsequent. Sie müssen nicht alle bauen. Der Product Owner wählt die Stories mit dem höchsten Mehrwert für jeden Sprint aus.

Beim Backlog Refinement. Sprint Planning ist zu spät, weil Sie Stories brauchen, die bereits verfeinert und geschätzt sind, bevor dieses Meeting stattfindet. Die meisten Teams teilen Epics 1-2 Sprints auf, bevor sie planen, daran zu arbeiten.

Spielen Sie Planning Poker. Wenn das Team jede Story schnell schätzen kann und die Schätzungen eng beieinander liegen (eine 3, eine 5 und eine 5 statt einer 2 und einer 13), funktioniert die Aufteilung. Grosse Streuungen bei der Schätzung bedeuten, dass die Story immer noch zu vage oder zu gross ist.
Zuletzt aktualisiert am 10/02/2026