Epic

Was sind Epics, wie grenzen sie sich von anderen Begriffen ab, wie werden sie formuliert und welche Tipps zur Anwendung gibt es?

Wissen kompakt: Nach der gängigen Definition ist ein Epic eine große, umfangreiche User Story. Alternativ kann es auch eine Gruppierung von Use Cases sein.

Epic Definition

Der Begriff „Epik“ war ursprünglich eine Bezeichnung für die Kunst des Epos, in der eine Handlung – meist in Versen – erzählt wurde. Mit zunehmender Differenzierung der epischen Dichtung sowie der Entwicklung der Prosa, wurde der Begriff erweitert, so dass Werke der erzählenden Literatur darunter summiert wurden. Ist ein Text „episch“, dann erzählt er umfangreich und ausführlich über eine Handlung.1

Die agile Produkt- und Softwareentwicklung nimmt diesen Gedanken der ausführlichen Beschreibung auf: Ein Epic ist eine  umfangreiche User Story, wobei umfangreich bedeutet, dass

  • das Epic zu groß für die Umsetzung innerhalb eines Sprints ist und/oder
  • in kleinere User Storys aufgeteilt werden kann.

 

Epic als große User Story oder Gruppierung von Use Cases

Abgrenzung zwischen Task, User Story, Epic, Theme und Feature

Es gibt eine ganze Reihe von Begriffen, die im Kontext von Epics auftauchen. Häufig ist die genaue Abgrenzung unklar: Ist ein Feature größer oder kleiner als ein Epic? Was ist ein Theme und was ist eine Task? Nachfolgend finden Sie „eine“ mögliche Abgrenzung:

  • Eine Task ist eine Tätigkeit zur Implementierung einer User Story. Der Fortschritt der Implementierung wird häufig per Taskboard visualisiert.
  • Im wörtlichen Sinne beschreibt eine User Story eine Geschichte eines Anwenders. User bedeutet Anwender oder Benutzer und Story bedeutet Geschichte. Im agilen Projektmanagement und in der agilen Produkt- und Softwareentwicklung ist eine User Story somit ein Werkzeug, um gewünschte Funktionalitäten eines Systems aus Sicht des Anwenders zu beschreiben.
  • Ein Epic ist eine große, umfangreiche User Story. Manchmal wird argumentiert, dass die Textlänge ein Unterscheidungsmerkmal wäre, dies sollte jedoch durch die Verwendung von Textschablonen nicht der Fall sein. Die Größe bezieht sich entweder auf den Aufwand zur Implementierung der gewünschten Funktionalität oder die Möglichkeit, das Epic in sinnvolle, kleinere User Storys aufzusplitten. Tatsächlich gibt es kein fixiertes Maß, ab wann von dem einen oder dem anderen gesprochen wird.
  • Ein Theme ist eine Gruppierung von User Storys anhand eines gemeinsamen Themas. Es ist ein Label2 bzw. ein Attribut und erleichtert die Kommunikation über Inhalte, die ein gemeinsames Thema haben. Themes werden normalerweise nicht als Backlog Items verwaltet.
  • Der BABOK Guide definiert ein Feature als „ein Unterscheidungsmerkmal einer Lösung, die einen zusammenhängenden Satz von Anforderungen implementiert und die einen Wert für eine Reihe von Stakeholdern liefert.“ Aus dieser Definition lassen sich zwei Erkenntnisse ableiten: Ein Feature beschreibt, was ein Produkt hat oder tut. Und es ist größer als ein Epic und lässt sich ggf. in (große) User Storys zerteilen.

Sicherlich gibt es Unternehmen, die andere Abgrenzungen verwenden. So gibt es bspw. eine alternative Interpretation von Theme, wonach es ein Unternehmensziel (oder eine Vision) darstellt, dass durch verschiedene Initiativen avisiert wird, die durch Epics in kleinere Einheiten gegliedert und ggfs. per Roadmap visualisiert werden.3 Ein Feature könnte einen Business Value adressieren oder auch eine Funktionalität eines Produkts benennen, die noch nicht detailliert beschrieben wurde. Und wenn ein Epic beschreibt, was ein Anwender mit einem Produkt erreichen möchte, dann könnte das Feature die Beschreibung der Funktion sein, mit der dies ermöglicht wird. Dann wäre ein Feature kleiner als ein Epic. Allerdings könnte ein Epic auch eine Gruppierung von Use Cases darstellen, wobei ein Theme dann einem Use Case und eine User Story in etwa einem Use Case Szenario oder einem Use Case Slice entspräche; in diesem Fall wäre ein Epic sehr viel größer als eine User Story.4

Grundsätzlich sind verschiedene Abgrenzungen und Interpretationen in Ordnung, sofern die Beteiligten einer Entwicklung, eines Projekts oder einer Kooperation ein gemeinsames Verständnis der Begriffe teilen und sie als Hilfsmittel für ihre Arbeit nutzen können.

Die Formulierung von Epics

Wenn ein Epic nichts anderes als eine große User Story ist, dann empfiehlt sich 1:1 die Verwendung von Satzschablonen. Die bekannteste ist vermutlich:

  • Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen.

Ein Beispiel könnte wie folgt lauten: „Als Hotelier möchte ich den optimalen Preis für meine Hotelzimmer finden, um im Wettbewerb mit anderen Hotels zu bestehen und meine Einnahmen zu maximieren.“

Natürlich eignen sich auch alternative Satzschablonen:

  • Um (Nutzen) als (Rolle) zu erreichen, möchte ich (Funktionalität/Ziel/Wunsch).
  • Als (Rolle) möchte ich (was) (warum).
  • Als (wer) (wann) (wo) möchte ich (was) (warum).

Alle Satzschablonen haben gemeinsam, dass sie absichtlich kurz gehalten und nicht allzu deskriptiv sind. Auch wenn es in vielen Unternehmen anders gehandhabt wird, ein Epic sollte eine Erinnerung an einen Austausch mit Anwendern, Benutzern oder Kunden und eine Dokumentation von wesentlichen Aspekten des Austauschs sein. Einerseits geht es darum, Informationen festzuhalten, andererseits ist es aber weniger wichtig, diese Informationen auf eine bestimmte Weise niederzuschreiben. In anderen Worten: die Art der Dokumentation ist sekundär.

Das Aufsplitten von Epics

Epics, Themes und User Storys gehen auf Extreme Programming (XP) und nicht wie häufig angenommen auf den Scrum Guide zurück. Auch wenn alle drei Elemente heutzutage in Scrum Projekten weltweit zur Anwendung kommen, im Scrum Guide werden sie nicht ein einziges Mal erwähnt.

Als Ausdrucksmittel erleichtern Epics die Verständigung zwischen Anwendern und Produkt- oder Softwareentwicklern und vermitteln ein Big Picture. Themes helfen bei der Strukturierung der Arbeit und User Storys liefern u.a. den Input für die Aufwandsschätzung, bspw. in Form von Story Points

Bevor ein Sprint beginnen kann, müssen die ausgewählten User Storys klein genug sein, um innerhalb eines Sprints realisiert werden. Der Begriff dazu lautet: User Story Splitting. Der Ausdruck Epic Splitting wird hingegen praktisch nicht genutzt. Hier ein Beispiel zum Splitting5:

  • E1: „Als Hotelier möchte ich den optimalen Preis für meine Hotelzimmer finden, um im Wettbewerb mit anderen Hotels zu bestehen und meine Einnahmen zu maximieren.“
  • US1: „Als Hotelier möchte ich den optimalen Preis für meine Hotelzimmer anhand der Preise des letzten Jahres festlegen, um aktiv Erfahrungen zu nutzen und Einnahmen zu maximieren.“
  • US2: „Als Hotelier möchte ich den optimalen Preis für meine Hotelzimmer anhand der Preise vergleichbarer Hotels festlegen, um wettbewerbsfähig zu sein.“
  • US3: „Als Hotelier möchte ich den optimalen Preis für meine Hotelzimmer an die voraussichtliche Belegung anpassen, um situativ auf Angebot und Nachfrage reagieren zu können.“

Aus einem Epic werden drei User Storys. Was passiert aber, wenn die User Storys noch zu groß sind? Dann werden Sie weiter verfeinert:

  • US2-1: „Als Hotelier möchte ich ein Set an vergleichbaren Hotels festlegen, um den optimalen Preis für meine Hotelzimmer anhand eines Preisvergleichs herauszufinden.“
  • US2-2: „Als Hotelier möchte ich Hotels zu dem Set von vergleichbaren Hotels hinzufügen können, um flexibel auf die Preisgestaltung neuer Konkurrenten reagieren zu können.“
  • US3-1: „Als Hotelier möchte ich den optimalen Preis für meine Hotelzimmer an die Mindestauslastung, die gewünschte Auslastung und eine Maximalauslastung anpassen, um optimal auf Angebot und Nachfrage reagieren zu können.

Tipps für die Nutzung von Epics

Es gibt eine Reihe von Tipps für die Nutzung von Epics:

  • Sie sollten unabhängig voneinander formuliert werden.
  • Ein gemeinsamer Themenbezug sollte bspw. in Form eines Baumdiagramms oder einer User Story Map visualisiert werden.
  • Akzeptanzkriterien sollten definiert werden. Findet sich mehr als ein Akzeptanzkriterium, handelt es sich um eine große User Story, die verfeinert werden sollte.
  • Das Splitting sollte gemeinsam im Team erfolgen.
  • Die Verwaltung im Backlog sollte nach dem DEEP Prinzip von Roman Pichler erfolgen: detailed appropriately (angemessen detailliert), estimated (geschätzt), emergent (entstehend) und prioritized (priorisiert).
  • Da sich in vielen Backlogs schnell mehrere tausende Einträge finden, lohnt es sich, spezialisierte Tools dafür zu nutzen.
  • Und last but not least: nicht alle Informationen müssen als Epics oder User Storys formuliert werden. Bei einem User Interface Design könnte bspw. eine Skizze oder ein Wireframe nützlicher sein.

Die Meinungen variieren, ob ein Epic nach seiner Verfeinerung „gelöscht“ werden sollte. Einerseits reduziert sich dadurch die Menge an Daten, die in einem System verwaltet werden. Andererseits bedeutet dies auch, dass ein Epic „vollständig“ in User Storys zerlegt wurde. Diese Vollständigkeit lässt sich aber nicht wirklich gewährleisten. Darüber hinaus wäre auch die Traceability nicht mehr gewährleistet. Und da alle gängigen Tools zur Verwaltung von Backlogs Sichten auf Elemente anbieten, die sich nach Eigenschaften filtern lassen, empfinden viele Anwender die Existenz von „implementierten“ Epics auch nicht als störend. 

Impuls zum Diskutieren:

Wenn ein Epic eine große User Story ist, wird dann aus einer User Story, die sich in weitere User Storys gliedern lässt, ein Epic?

Hinweise:

[1] Ursprünge von Epik und episch
[2] User Stories, Epics and Themes
[3] Grundlegendes zu Epics
[4] Die Alternative zu Epics
[5] Aufsplitten von Epics

In Jira gibt es einen Vorgangstypen „Subtask“. Theoretisch ist es zwar denkbar, dass eine Task in kleinere Tätigkeiten aufgeteilt wird, tatsächlich dürfte aber die Verwendung der Subtask eher dem Umstand geschuldet sein, dass Jira das Anlegen einer Task als Backlog Item ermöglicht. In der Folge wird eine weitere Unterscheidung für die Implementierung benötigt.

Im Zuge der Gestaltung von Websites wird der Begriff Theme häufig benutzt. Ein Theme beeinflusst durch Farben, Layout und Stilelementen das Look and Feel einer Website.

Es ist natürlich keine Alternative die Sprintdauer zu verlängern, nur um die Implementierung eines Epics innerhalb eines Sprints zu gewährleisten.

Hier finden Sie ergänzende Informationen aus unserem Blog:

t2informatik Blog: Boost your Backlog - Teil 1

Boost your Backlog – Teil 1

t2informatik Blog: Anforderungen eliminieren

Anforderungen eliminieren

t2informatik Blog: Anforderungsmanagement mit Jira und Confluence

Anforderungsmanagement mit Jira und Confluence