Epics, Features und User Stories erklärt

Die meisten Agile-Teams kennen die Begriffe. Weit weniger sind sich einig, was sie bedeuten. Epics vs. Features vs. Stories ist eine der meistgesuchten Fragen im Produkt- und Projektmanagement, weil Teams die Ebenen regelmäßig durcheinanderbringen und damit Backlogs erzeugen, die entweder viel zu vage oder viel zu kleinteilig für eine sinnvolle Planung sind.

Die Hierarchie korrekt zu beherrschen ist keine Übung in Bezeichnungen. Es geht darum, eine sechsmonatige strategische Initiative mit der zweitägigen Aufgabe zu verbinden, die ein Entwickler am Montagmorgen aufnimmt.

Was sind Epics, Features und User Stories?

Epics, Features und User Stories sind drei Ebenen einer Anforderungshierarchie in der Agile-Planung. Ein Epic ist ein großes Arbeitspaket, das sich über mehrere Sprints erstreckt. Ein Feature ist ein auslieferbarer Ausschnitt dieses Epics, der eine eigenständige Funktionalität darstellt. Eine User Story ist eine einzelne, kleine Werteeinheit, die ein Team in einem Sprint oder weniger liefern kann.

Die drei Ebenen sind ineinander verschachtelt: Ein Epic enthält mehrere Features, jedes Feature enthält mehrere User Stories. Zusammen bilden sie das Fundament eines gesunden Product Backlog.

Wichtige Fakten

• Teams, die Anforderungen in klare Hierarchien aufschlüsseln, berichten 27 % weniger Scope-Change-Fehler als Teams mit flachen Backlogs (Standish Group CHAOS Report, 2023).
• Der State of Agile Report ergab, dass 68 % der Unternehmen eine "inkonsistente Backlog-Struktur" als wesentlichen Grund für verfehlte Sprint-Ziele nennen (Digital.ai, 2024).
• Schlecht definierte Akzeptanzkriterien sind die häufigste Ursache für Nacharbeit, die Teams im Durchschnitt 20 bis 25 % der gesamten Projektzeit kostet (PMI Pulse of the Profession, 2023).

Zu verstehen, wo jede Ebene beginnt und endet, ist der schnellste Weg, Planungsreibung und Sprint-Überläufe zu reduzieren.

Epic vs. Feature vs. User Story: die Hierarchie

Die folgende Tabelle zeigt, wie sich jede Ebene in der Praxis verhält. Die entscheidenden Unterschiede sind Umfang, Zeithorizont und Verantwortung, nicht nur die Größe.

Stellen Sie sich das wie ein Zoomobjektiv vor. Das Epic ist die Weitwinkelaufnahme (das Ziel ist klar, nicht aber jede Abbiegung). Features sind die Streckenabschnitte. User Stories sind die einzelnen Anweisungen: links abbiegen, 200 Meter geradeaus, hier parken.

Einen genaueren Blick darauf, wie Stories selbst aufgebaut sind, bietet der Leitfaden zu User Stories und die Referenz zu Akzeptanzkriterien.

Vorteile der Aufschlüsselung in diese Hierarchie

Eine dreigliedrige Hierarchie tut mehr, als den Backlog zu strukturieren. Sie löst echte Koordinationsprobleme.

Roadmap-Klarheit auf jeder Ebene. Führungskräfte und Stakeholder können den Fortschritt auf Epic-Ebene verfolgen, ohne in Story-Details zu ertrinken. Entwickler können sich auf Stories konzentrieren, ohne den vollständigen strategischen Kontext jedes Quartals zu kennen. Features verbinden beide Ebenen.

Vorhersehbare Sprint-Planung. Wenn Stories korrekt dimensioniert sind, können Teams einen Sprint zuverlässig füllen, ohne zu viel zu versprechen. Die Schätzung mit Story Points funktioniert nur, wenn die Story tatsächlich klein genug zum Schätzen ist.

Sichtbare Abhängigkeiten. Features hängen oft voneinander ab. Werden diese Abhängigkeiten auf Feature-Ebene sichtbar gemacht statt erst auf Story-Ebene mitten im Sprint, lassen sich kurzfristige Blockaden vermeiden.

Besseres Backlog Refinement. Refinement-Sessions sind schneller, wenn das Team nicht gleichzeitig Umfang und Implementierung diskutiert. Epics und Features rahmen das "Was" ein, sodass sich das Refinement auf das "Wie" konzentrieren kann.

Die Hierarchie macht auch Umfangsausweitung sichtbar. Passt eine neue Anforderung in kein bestehendes Epic, wird sie zu einem eigenen Epic, was eine bewusste Priorisierungsdiskussion erzwingt, statt den Backlog still aufzublähen.

Häufige Fehler

Teams, die die Definitionen kennen, tappen trotzdem in vorhersehbare Fallen.

Stories, die zu groß sind. Der häufigste Fehler. Wenn eine Story mehr als ein paar Tage dauert oder mehrere Personen unabhängig voneinander aufnehmen müssen, ist sie eigentlich ein Feature, das sich als Story tarnt. Ein Anzeichen: Jede Story, in der im Nutzenvorteil ein "und" vorkommt, sind wahrscheinlich zwei Stories.

Epics, die nie geschlossen werden. Ein Epic, das dauerhaft offen bleibt, wird zum Auffangbecken. Es verliert seine Bedeutung als Planungseinheit. Epics sollten eine klare Definition of Done haben: eine Reihe ausgelieferter Features, die zusammen die strategische Fähigkeit bereitstellen.

Fehlende Akzeptanzkriterien. Eine User Story ohne Akzeptanzkriterien ist ein Wunsch, keine Verpflichtung. Das Team kann sie nicht testen, und das Produkt kann sie nicht abnehmen. Jede Story braucht mindestens ein Kriterium, das bestätigt, dass der Wert geliefert wurde.

Features, die mit Themen verwechselt werden. Themen gruppieren Epics nach strategischem Bereich ("Kundenbindung"). Features sind auslieferbar: Ein Feature kann man Nutzern bereitstellen. Ein Thema nicht. Diese Unterscheidung klar zu halten verhindert, dass Features im Laufe der Zeit zu Themen werden.

Die Feature-Ebene ganz überspringen. Manche Teams schreiben Epics und schlüsseln sie direkt in Stories auf. Das funktioniert im sehr kleinen Maßstab, erzeugt aber Backlogs mit Hunderten ungruppierten Stories ohne Zwischenstruktur für Quartalsplanung oder Abhängigkeitsverfolgung.

So schlüsselt man ein Epic in Features und Stories auf

Der Zerlegungsprozess ist wiederholbar. Hier wird er auf ein konkretes Beispiel angewendet: ein Checkout-Flow-Epic für ein B2B SaaS-Produkt.

Schritt 1: Epic als Business-Ergebnis formulieren

Schreiben Sie das Epic als Ziel, nicht als Feature-Liste. Gut: "Käufern ermöglichen, einen Kauf abzuschließen, ohne den Vertrieb zu kontaktieren." Schlecht: "Checkout-Bildschirm bauen."

Schritt 2: Die wichtigsten Funktionalitätsausschnitte identifizieren (Features)

Fragen Sie: Welche eigenständigen, auslieferbaren Fähigkeiten erfordert dieses Epic? Jede Antwort ist ein Feature-Kandidat. Für das Checkout-Epic:

• Gast-Checkout (kein Login erforderlich)
• Gespeicherte Zahlungsmethoden
• Bestellübersicht und Bestätigung
• Eingabe von Rabattcodes
• Steuer- und Versandberechnung

Jeder dieser Punkte könnte eigenständig ausgeliefert werden und Nutzern Mehrwert bieten.

Schritt 3: User Stories für jedes Feature schreiben

Für "Gast-Checkout" könnten die Stories lauten:

• "Als Gast kann ich meine E-Mail-Adresse eingeben, damit ich eine Bestellbestätigung erhalte."
• "Als Gast kann ich meine Rechnungsadresse eingeben, ohne ein Konto zu erstellen."
• "Als Gast kann ich meinen Warenkorb überprüfen, bevor ich die Bestellung aufgebe."

Wenden Sie die INVEST-Kriterien (siehe Best Practices unten) auf jede Story an, bevor sie in einen Sprint übernommen wird.

Schritt 4: Akzeptanzkriterien zu jeder Story hinzufügen

Jede Story erhält mindestens ein prüfbares Kriterium. Für die Story zur E-Mail-Eingabe: "Wenn ein Nutzer eine gültige E-Mail-Adresse eingibt und das Feld absendet, speichert das System sie und zeigt eine Bestätigungsmeldung an."

Schritt 5: Features nach Abhängigkeit und Wert sequenzieren

Nicht alle Features sind gleichwertig. Gast-Checkout ist eine Voraussetzung für Rabattcodes, die wiederum von der Preislogik abhängen. Kartieren Sie die Abhängigkeitskette auf Feature-Ebene, bevor Sie die Sprint-Reihenfolge festlegen.

Dieser fünfstufige Prozess gilt für jede Domäne. Ersetzen Sie das Checkout-Beispiel durch einen Onboarding-Flow, ein Reporting-Modul oder eine Marketing-Automatisierungssequenz, und die Logik bleibt dieselbe.

Beispiele nach Team

Verschiedene Funktionsbereiche verwenden dieselbe Hierarchie, aber der Inhalt sieht sehr unterschiedlich aus.

Zu beachten ist, dass jede User Story unabhängig vom Team dieselbe Form hat: wer der Nutzer ist, was er tun muss und warum. Die "Warum"-Klausel ist es, die eine Aufgabe in eine Story mit echten Akzeptanzkriterien verwandelt.

Best Practices

Verwenden Sie die INVEST-Kriterien für Stories. Eine gut formulierte User Story ist: Independent (kann ohne eine andere Story bearbeitet werden), Negotiable (Umfang ist nicht festgeschrieben), Valuable (liefert echten Nutzerwert), Estimable (Team kann sie schätzen), Small (passt in einen Sprint), Testable (hat Akzeptanzkriterien). Prüfen Sie jede Story, bei der Sie unsicher sind, anhand dieser Liste, bevor sie in den Sprint kommt.

Vertikal schneiden, nicht horizontal. Ein horizontaler Schnitt liefert eine Schicht des Tech-Stacks (z. B. "Datenbankschema für Checkout aufbauen"). Ein vertikaler Schnitt durchschneidet alle Schichten und liefert sichtbaren Nutzerwert (z. B. "Gast kann eine Bestellbestätigung sehen"). Vertikale Schnitte ermöglichen schnelleres Feedback und frühere Releases.

WIP-Limits auf Feature-Ebene setzen. Features als Work-in-Progress-Elemente zu behandeln, nicht nur als Organisationsbehälter, hilft Teams zu vermeiden, zu viele Features parallel zu beginnen. Das Scrum-Framework empfiehlt, gleichzeitige Arbeit zu begrenzen, um den Fluss zu verbessern.

Epics quartalsweise, Features pro Sprint, Stories täglich überprüfen. Der Planungsrhythmus sollte dem Umfang entsprechen. Epics gehören in vierteljährliche Roadmap-Reviews. Features gehören in die Sprint-Planung. Stories gehören in das tägliche Standup. Diese Rhythmen zu vermischen ist eine häufige Quelle von Planungsaufwand.

Epics mit den Zielen der agilen Methodik verknüpfen. Jedes Epic sollte auf ein Business-Ziel (OKR, Objective and Key Result oder Quartalsziel) zurückzuführen sein. Kann ein Epic nicht mit einem Ziel verknüpft werden, ist es ein Kandidat für den Backlog, nicht für die aktive Roadmap.

Für Teams, die über mehrere Produktlinien hinweg arbeiten oder skalieren, fügt das Scaled Agile Framework (SAFe) zwei weitere Ebenen über Epics hinzu: Capabilities und Portfolio-Epics. Und wer die häufige Frage klärt, wie Scrum-Praktiken auf Agile-Prinzipien zutreffen, findet in dem Vergleich Agile vs. Scrum Orientierung.

Häufig gestellte Fragen

Ist ein Feature dasselbe wie ein Thema?

Nein. Ein Thema ist eine Bezeichnung, die verwandte Epics für die Roadmap-Kommunikation gruppiert (zum Beispiel "Zuverlässigkeit" oder "Wachstum"). Es hat keine Lieferverpflichtung. Ein Feature ist eine auslieferbare Fähigkeit innerhalb eines Epics. Themen organisieren Epics; Features schlüsseln sie auf.

Wie viele User Stories sollte ein Epic enthalten?

Es gibt keine feste Zahl, aber ein praktikabler Bereich liegt bei 10 bis 30 Stories über alle Features eines Epics hinweg. Weniger als 10 deutet darauf hin, dass das Epic eigentlich ein Feature sein könnte. Mehr als 50 bedeutet oft, dass das Epic zu breit ist und in zwei separate Epics mit eigenen Zielen aufgeteilt werden sollte.

Haben Epics Story Points?

Nicht im klassischen Sinne. Story Points werden verwendet, um die relative Komplexität einzelner User Stories zu schätzen, da dort die Unsicherheit klein genug ist, um nützlich zu sein. Epics werden in größeren Einheiten geschätzt: T-Shirt-Größen (S/M/L/XL) oder ungefähre Sprint-Anzahlen. Story Points auf Epic-Ebene zu verwenden erzeugt falsche Präzision.

Wann sollte ich ein Feature in zwei Features aufteilen?

Teilen Sie auf, wenn: das Feature zwei verschiedene Nutzerreisen abdeckt, wenn ein Teil eigenständig ausgeliefert werden und Mehrwert bieten könnte, oder wenn ein Teil eine deutlich längere Lieferzeit hat als der andere. Wenn Sie eine Feature-Beschreibung schreiben und "und" verwenden, um zwei verschiedene Fähigkeiten zu verbinden, ist das ein Signal zum Aufteilen.

Kann eine User Story außerhalb eines Epics existieren?

Ja, technisch gesehen. "Tech Debt", "Spike" und andere nicht-Feature-Arbeitselemente werden oft als Stories ohne übergeordnetes Epic geschrieben. Für jede kundenorientierte oder produktbezogene Arbeit werden Stories ohne übergeordnetes Feature oder Epic jedoch zu verwaisten Backlog-Elementen ohne sichtbaren Kontext. Versuchen Sie, sie wann immer möglich einem übergeordneten Element zuzuordnen.

Weiterführende Lektüre

• User Stories
• Product Backlog
• Backlog Refinement
• Story Points
• Akzeptanzkriterien
• Definition of Done
• Was ist Agile Methodology?
• Agile vs. Scrum
• Scaled Agile Framework (SAFe)

Die Hierarchie richtig zu beherrschen ist eine Investition, die sich jeden Sprint auszahlt. Teams, die sich darüber einigen, was ein Epic gegenüber einem Feature gegenüber einer Story ist, streiten in der Planung nicht mehr über den Umfang und liefern stattdessen zuverlässig. Beginnen Sie mit einem Epic, schlüsseln Sie es nach dem fünfstufigen Prozess oben auf und nutzen Sie es als gemeinsame Referenz für jedes Planungsgespräch, das folgt.