Epic

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 Label² 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.³ 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.⁴

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 Epic Splitting

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 Splitting⁵:

• 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, ist dann eine User Story, die sich in weitere User Storys gliedern lässt, auch ein Epic?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[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:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.