Epic

Eine User Story ist klein (passt in einen Sprint). Ein Epic ist groß. Beispiel: "Neue Bezahlmethoden einführen". Das schafft man nicht in 2 Wochen. Man zerteilt das Epic in viele kleine Stories:

"PayPal bezahlen"
"Kreditkarte bezahlen"
"Rechnung downloaden" Das Epic ist der "Container" oder die Überschrift für all diese Aufgaben.

Merksatz: Eine große Anforderung oder ein umfangreiches Feature in der agilen Entwicklung, das zu groß für einen einzelnen Sprint ist und daher in mehrere kleinere User Stories unterteilt werden muss.

Im Backlog (Jira): Stories haben Farben (Blau). Epics haben Farben (Lila). Jira zeigt dir einen Balken: "Epic 'Bezahlung' ist zu 40% fertig." Epics helfen dem Management, den Überblick über große Ziele zu behalten, ohne sich in Details zu verlieren.

1. Initiative vs. Epic

In riesigen Firmen (SAFe) gibt es noch mehr Ebenen:

Initiative: "Wir wollen Marktführer in Asien werden." (Jahre).
Epic: "Chinesische Sprache und WeChat-Login unterstützen." (Quartale).
Story: "Button für WeChat Login einbauen." (Tage).
Sub-Task: "Icon ausschneiden." (Stunden).

2. Burndown Chart

Man kann tracken, wann ein Epic fertig wird. Wenn wir 5 Punkte pro Sprint schaffen und das Epic noch 50 Punkte hat -> 10 Sprints. So plant man Roadmaps ("Wann kommt das Feature?").

3. Scope Creep

Gefahr! Ein Epic wird oft zum "Mülleimer". "Pack das auch noch ins Bezahl-Epic!" Das Epic wird nie fertig. Regel: Ein Epic muss ein definiertes Ende haben. Wenn es zu groß wird, splitte es ("Bezahlung V1" und "Bezahlung V2").

1. Portfolio Kanbans und WSJF (Weighted Shortest Job First)

Epics im Management-Level werden nicht stur nach "Wer schreibt das Ticket lauter" priorisiert. Im SAFe Framework laufen Epics durch einen harten "Portfolio Kanban". Bevor ein Entwickler auch nur ein Wort liest, muss ein Epic die Stadien "Funnel" -> "Review" -> "Analysis" durchlaufen. Die absolute Priorisierungskennzahl ist WSJF. WSJF = (User Value + Time Criticality + Risk Reduction) / Job Size. Ein Epic, das massiven Kunden-Schmerz löst (Value = 9) und nur einen Monat dauert (Size = 2), ergibt 4.5. Ein riesiges Rewrite-Epic (Value = 5, Size = 10) ergibt 0.5. Das 4.5er Epic gewinnt gnadenlos das Budget.

2. Epic Slicing (Die Kunst des Zerschneidens)

Ein Monster-Epic "Neues Backend" dauert laut Schätzung 10 Monate (ein Anti-Pattern, "Water-Scrum-Fall"). Agile Master betreiben Vertikales Schneiden (Vertical Epic Slicing). Schneide nicht horizontal in "Epic: DB-Layer", "Epic: Business-Logic", "Epic: UI". Das bringt dem Kunden 8 Monate lang exakt null Wert (kann er ja nicht nutzen). Schneide vertikal nach Use-Case: "Epic: Nur der Gast-Nutzer Checkout in DE". Das betrifft alle Layer (DB, Logic, UI), ist aber so dünn ("Thin Slice"), dass es nach 4 Wochen live gehen kann. Der Code ist dreckig (Hardcoded für DE), aber das Risiko ist minimiert und Feedback kommt früh.

3. Visiualisierung mit dem Lean Portfolio Management (LPM)

Auf Epic-Ebene agiert das LPM-Team. Epics werden nicht einfach abgehakt. Sie generieren Epic Hypothesis Statements. "Wir glauben, wenn wir Feature X bauen, erhöht sich Conversion Y." Sobald das Epic durch ist (MVP-Launch), beginnt die Leading Indicators Messung. Stimmt die Hypothese nicht (Kunden klicken den Button nicht), wird das Epic brutal gestoppt ("Pivot or Persevere"), selbst wenn laut Plan noch 20 Stories für das Epic im Backlog schlummern. Diese agilen Metriken bewahren Firmen vor "Feature Factories".