Epics im agilen Projektmanagement

Neben den User Stories existieren im agilen Projektmanagement auch andere Product Backlog-Eintrage wie Themes oder Epics. Doch was genau sind Epics, wie setzen sie sich zusammen, oder wie können diese von User Stories unterschieden werden? Diese Fragen sind Ihnen vielleicht auch schon einmal durch den Kopf gegangen. Daher haben wir Ihnen in diesem Artikel die wichtigsten Informationen über Epics zusammengestellt.

Epics dienen der Verwaltung des Arbeitsvolumens und der Strukturierung von Aufgaben. Diese können Bestandteil des Product Backlogs sein und sind Teil des agilen Managements. Es handelt sich hierbei um sehr umfangreiche Anforderungen, die zum Zeitpunkt der Bewertung noch zu groß sind, um in einer User Story erfasst werden zu können. 
Wie bei allen Product Backlog-Einträgen, müssen die Anforderungen zunächst spezifisch und messbar beschrieben sein, damit sie zur Zielerreichung beitragen zu können. Zudem sind Epics auf die strategischen Projektziele abzustimmen, nur dann können diese erfolgreich umgesetzt werden. Dies fördert langfristig die Kommunikation zwischen Anwendern und Entwicklern.
Einige Epics können sich auch über mehrere Teams oder teilweise sogar über mehrere Projekte erstrecken. Darüber hinaus erleichtern Epics die Priorisierung von Aufgaben und verbessern damit die Arbeitsabläufe im Projekt. Ebenso fördern sie die Transparenz. Um sie im Projektverlauf besser umsetzen zu können, werden Epics in User Stories unterteilt, welche Wünsche und kurz formulierte Anforderungen an ein Endprodukt darstellen. Die User Stories wiederum sind vor allem für die Umsetzung und Aufwandsabschätzung von Bedeutung.

Epics gehen Hand in Hand mit User Stories und können nicht von ihnen getrennt betrachtet werden, dennoch müssen die einzelnen Epics unabhängig voneinander formuliert sein.
Bei der Erstellung und Strukturierung ist es von Vorteil, wenn das Team in den Prozess eingebunden wird, da so die Ziele und zugehörigen Aufgaben besser verstanden werden und somit die Entwicklung erleichtert wird. Es gibt verschiedene Möglichkeiten, dies zu erreichen: 

Top-down

Die zuvor identifizierten Epics werden in User Stories zerlegt, welche danach für die Umsetzung im darauffolgenden Entwicklungszyklus priorisiert werden. Nur wenn die Epics in genau definierte User Stories zerlegt werden, kann die Umsetzbarkeit gewährleistet werden. 

Bottom-up

Aus einer Anzahl an thematisch zusammenhängenden User Stories können Epics abgeleitet werden, indem die User Stories zusammengeführt werden.Werden die Epics vor der Erstellung der User Stories definiert (Top-down), schafft dies einen besseren Überblick über die durchzuführende Arbeit. Grund dafür ist, dass User Stories zu detailliert sind, um das Gesamtbild zu erkennen. Dennoch kommt es manchmal vor, dass eine bestimmte Anforderung vorliegt, welche dann in ein Epic integriert werden muss. Es ist also kein Entweder-Oder, sondern eine projekt- oder einzelfallbezogene Abwägung.
Verwendung finden Epics unter anderem im agilen Framework Scrum oder in der Methode Kanban. 
Im Scrum werden die Epics in einem Product Backlog priorisiert. Je detaillierter die Formulierung der Anforderungen, desto höher ist in der Regel die Priorisierung. Das bedeutet, dass User Stories weiter oben im Product Backlog stehen, da diese bereits ausformuliert wurden und Epics weiter unten vorzufinden sind, da sie noch zu groß und zu ungenau beschrieben sind. Zusätzlich ist es im Scrum wichtig, dass User Stories gewissen Verwaltungskriterien (bspw. den DEEP-Kriterien) entsprechen. Werden diese beispielsweise nach den DEEP-Kriterien verwaltet, müssen diese die folgenden Kriterien erfüllen: detailed appropriately (angemessen detailliert), estimated (geschätzt), emergent (entstehend) und prioritised (priorisiert). Sobald eine User Story diese Kriterien erfüllt, kann sie aus dem Product Backlog in das Sprint Backlog übernommen und im Entwicklungszyklus, dem Sprint, umgesetzt werden. Aufgrund des zuvor genannten Zusammenhangs zwischen User Stories und Epics wird sichergestellt, dass das Team über mehrere Sprints und Iterationen das strategische Ziel nicht aus den Augen verliert, da die Epics ebendiese dieses verfolgen.
Bei Kanban hingegen wird digital oder analog mit einem Kanban Board gearbeitet. Auf diesem befinden sich Kanban-Karten, welche die Epics enthalten und vom Team in User Stories unterteilt wurden. Je nach freien Kapazitäten werden diese nach dem Pull-System auf den Work-in-Progress Stack gezogen, also den Stapel, auf dem sich alle Karten befinden, die gerade in Bearbeitung sind.

Wie im vorherigen Abschnitt beschrieben, gehen die beiden Projektmanagementansätze unterschiedlich mit der Verwendung von Epics um. Gemeinsam ist ihnen jedoch, dass in beiden Fällen mehr Transparenz entsteht, der Workflow verbessert wird und nur die User Stories zu den entsprechenden Epics bearbeitet werden, die auch wirklich detailliert genug sind und zu den strategischen Zielen passen. Wenn das Team an der Erstellung der Epics beteiligt ist, versteht jeder die Ziele, die erreicht werden sollen, was die Motivation erhöht und sicherstellt, dass das Produkt rechtzeitig und vor allem erfolgreich fertiggestellt werden kann. Außerdem werden Missverständnisse vermieden, da alle Informationen zu jedem Zeitpunkt bekannt sind. 
Ein weiterer wichtiger Punkt ist, dass der Aufwand der Epics geschätzt werden muss. Im Scrum ist dies z. B. wichtig, damit die maximale Sprintdauer nicht überschritten wird. Dazu wird häufig das Burn-Down-Chart verwendet. Dabei wird der Aufwand der noch offenen Aufgaben für den Sprint mit Hilfe von Story Points geschätzt. Mit diesen Punkten geben die Teammitglieder an, wie aufwendig die Bearbeitung voraussichtlich sein wird. Daraus lässt sich jedoch noch nicht direkt die Bearbeitungsdauer ableiten. Hier kommt die Velocity ins Spiel, eine Kennzahl, die die Geschwindigkeit eines Implementierungsteams bestimmt. Die durchschnittliche Velocity wird in Punkten ausgedrückt, d. h. wie viele Funktionen ein Team durchschnittlich pro Sprint implementieren kann. Die geschätzten Story Points des Teams werden dann mit den Punkten der Velocity verglichen, um so eine möglichst realistische Zeitschätzung für die Implementierung einer Funktion in agilen Projekten zu erhalten. Das Ergebnis ist ein Balkendiagramm, bei dem die Balken nach rechts auf der X-Achse immer kleiner werden. Wird nun eine Gerade durch die Balkenspitzen gelegt, zeigt dies den idealen Burn-down an, also die Anzahl an Story Points, die das Entwicklungsteam pro Sprint-Tag erledigt. Die Ideallinie kann dann mit den täglich erfassten Ist-Zeiten verglichen werden, um mögliche Verzögerungen zu antizipieren und auch für spätere Sprints abzuschätzen, wie viel Zeit für ähnliche User Stories benötigt wird.
In Kanban wird ein kumulatives Flussdiagramm verwendet, das visuelle Unterstützung bietet und die Stabilität des Workflows analysiert, um den Prozess vorhersehbarer zu machen. Auf diese Weise können Engpässe, die entstehen können, wenn das Team zu viele Aufgaben gleichzeitig erledigt, vermieden oder aufgefangen und der Zeitplan eingehalten werden.

Durch die Bündelung von Anforderungen helfen Epics vor allem dabei die strategischen Ziele im Auge zu behalten. Sie unterstützen dabei, große und komplexe Aufgaben überschaubar zu halten und in gut handhabbare Abschnitte zu unterteilen. Ebenso verbessern Epics im Projektalltag die Transparenz und Kommunikation im Team und helfen dabei, den Workflow zu verfolgen und zu steuern.