Ein Epic in der Scrum Methodik ist eine Aufgabe von beträchtlicher Größe, die man nicht in einem einzigen Durchlauf erledigen kann. Epics können in kleinere User Stories aufgeteilt und dann dem Product Backlog hinzugefügt werden. Dabei handelt es sich eigentlich um ausführliche User Stories, welche zu umfangreich sind, um innerhalb eines Sprints abgeschlossen zu werden. Ein Epic erstreckt sich möglicherweise über mehrere Sprints oder sogar verschiedene Agile Teams hinweg und dient als übergreifende Aufgabe, an der gleichzeitig mehrere Teams arbeiten können. Die Grundidee besteht darin, den Kundennutzen kontinuierlich zu verbessern, indem große Projekte in kleinere Bestandteile zerlegt werden.
Diese kleineren Bestandteile – auch bekannt als User Stories – enthalten knappe Beschreibungen eines Produkts oder einer Dienstleistung aus der Perspektive des Kunden. Durch diesen gesamten Prozess kannst du deine Arbeit effektiv organisieren sowie Flexibilität gewährleisten und dich auf die Bedürfnisse deiner Kund*innen konzentrieren. Darüber hinaus fördert er divergentes Denken: Die Teams haben hierbei die Möglichkeit kreative Ideen im Hinblick auf den Kunden zu brainstormen.
Die Epic Hierarchie
Die Epic Hierarchie der Arbeit stellt eine hierarchische Struktur im agilen Prozess dar, bei der Epics die höchste Ebene einnehmen, gefolgt von Features und schließlich User Stories. Man kann sich diese agile Hierarchie wie ein Buch vorstellen: Ein einzelnes Epic ist das gesamte Buch, die Features sind, die Kapitel und die User Stories entsprechen den Absätzen. Diese Buchstruktur erleichtert das Verständnis der Geschichte und ermöglicht es einem, sich darin zu bewegen. Die Abschnitte helfen dabei, dem Inhalt jedes Kapitels zu folgen und ihn zu verstehen. Das Lesen jedes Kapitels bringt einen näher ans Ende des Buches. Dieses Format ist besonders nützlich für Projektteams im agilen Kontext. Es legt eine Arbeitsreihenfolge fest, was die Verwaltung größerer Initiativen vereinfacht und gleichzeitig ein besseres Verständnis für Kundenbedürfnisse ermöglicht. Zudem unterstützt es Teams dabei, agile Artefakte basierend auf Kundenerwartungen und größtem Kundennutzen priorisieren zu können.
- Epics sind die größte Einheit im agilen Backlog und bilden die Basis für die Aufteilung in kleinere, umsetzbare Teile – die User Stories und Features.
Epic vs. Feature: Was ist der Unterschied?
Obwohl das Epic an der Spitze der Hierarchie steht, bieten die Merkmale detailliertere Informationen zur Entwicklung eines Produkts. Ein Feature ist eine Funktion, die sie den Endbenutzern zur Verfügung stellen. Ein Beispiel für ein Feature könnte eine Suchfunktion in Ihrem Kunden-Dashboard sein. Dies ermöglicht es den Kunden, benötigte Informationen schnell zu finden und verbessert ihre Gesamterfahrung sowie den Wert Ihres Produkts. Diese Funktion wird Teil eines Epics und weitere Details sind in den User Storys enthalten. Features lassen sich im Gegensatz zu User Storys nicht so einfach in Sprints integrieren.
- Ein Feature ist eine spezifische Funktion oder Eigenschaft, die innerhalb eines Epics realisiert wird.
- Epics stellen einen breiter gefassten, strategischen Rahmen dar, wohingegen Features konkrete Elemente dieses Rahmens sind.
Epic vs. User Story: Was ist der Unterschied?
Ein Epic besteht aus einer Sammlung von Features und User Storys, was bedeutet, dass sie nicht dasselbe sind. Hier sind einige wichtige Unterschiede: Ein Epic ist ein Projekt, das für einen einzelnen Sprint zu groß oder zu komplex ist, während eine User Story die Beschreibung eines Features aus Sicht des Benutzers darstellt. Epics bieten einen Überblick über die Arbeit, während User Storys detaillierter und spezieller sind. Weiterhin werden sie nach ihrem Gesamtwert für das Unternehmen priorisiert, während Priorisierungskriterien bei User Storys ihre Bedeutung innerhalb des jeweiligen Epics berücksichtigt werden.
- User Stories beschreiben Funktionalitäten aus der Perspektive des Endnutzers, um einen bestimmten Wert zu liefern.
- Epics sind umfassender und abstrakter, meistens setzen sie sich aus mehreren User Stories zusammen.
Welche Vorteile ergeben sich aus der Verwendung von Epics?
Epics tragen dazu bei, das Projektmanagement zu verbessern, Stakeholder einzubeziehen, die Teamarbeit zu fördern und die Anpassungsfähigkeit an veränderte Anforderungen zu ermöglichen. Im Folgenden sind einige der wichtigsten Vorteile aufgeführt:
- Flexibilität: Durch den agilen Ansatz des Projektmanagements können Teams flexibel auf veränderte Kundenanforderungen reagieren. Die User Stories, also die beschreibenden Teile eines Epics, können sie überarbeiten, um Aufgaben zur richtigen Zeit priorisieren zu können.
- Kundenzentrierung: Epics stellen den Fokus auf deine Arbeit in Bezug auf die Bedürfnisse der Kunden. Sie betrachten Funktionen und Geschichten aus Sicht der Kunden und gewährleisten so ein besseres Verständnis für deren Wünsche und wie sie diese erfüllen können.
- Vereinfachung komplexer Projekte: Durch Untergliederung ihrer Arbeit in kleinere Aufgaben wird sie besser bewältigbar machen. Dadurch vereinfachen sie ihr Arbeitspensum und es entsteht keine Überlast.
- Sichtbarkeit und Transparenz: Epics bieten eine klare Zusammenfassung von Features oder Funktionalitäten, was allen Beteiligten ermöglicht, den Umfang und die Ziele der Arbeit zu verstehen.
- Zusammenarbeit und Abstimmung: Als Kommunikationsmittel erleichtern Epics die Zusammenarbeit zwischen Teammitgliedern sowie Interessengruppen-und-Kundenabstimmungen.
Es sorgt auch für ein gemeinsames Verständnis aller Gesamtziele und hilft dabei, eine einheitliche Sprache für die Diskussion und Planung der Arbeit zu schaffen.
So schreiben sie effektive Epics in der agilen Entwicklung
Nun, da wir wissen, was ein Epic ist und wie es funktioniert, möchten wir die Schritte aufzeigen, um Epics erfolgreich in ihrem eigenen Projekt einzusetzen. Um dies zu verdeutlichen, verwenden wir die Entwicklung von Apps als Beispiel für ein agiles Epic.
- Auswahl der geeigneten Plattform:
- Einsatz von Tools wie Jira, um Epics, User Stories und Fortschritte nachzuverfolgen.
- Namensgebung für das Epic:
- Der Name sollte klar und beschreibend sein, um den Inhalt und das Ziel des Epics widerzuspiegeln.
- Bestimmung des Umfangs:
- Festlegen der Grenzen des Epics und dessen, was es erreichen soll.
- Definieren von Abnahmekriterien:
- Klare Kriterien, die definieren, wann das Epic erfolgreich abgeschlossen ist.
- Aufteilung des Epics in User Storys:
- Zerlegen des Epics in kleinere, handhabbare Stories, die in überschaubaren Zeitfenstern umgesetzt werden können.
- Teile das Epic mit dem Team:
- Sicherstellen, dass alle Teammitglieder das Epic verstehen und den Wert dahinter erkennen.
- Anpassung und Aktualisierung des Backlogs nach jedem Sprint:
- Rückmeldungen aus jeder Iteration nutzen, um das Epic und zugehörige User Stories anzupassen und zu verbessern.
1. Auswahl der geeigneten Plattform
Beginnen sie damit, eine Plattform zu finden, mit der sie ihr Projekt verfolgen und organisieren können. Eine gute Arbeitsmanagementplattform ermöglicht es ihnen auch den Fortschritt der Epics im Auge zu behalten. Hier sind einige wichtige Funktionen einer solchen Plattform:
- Flexibles Aufgabenmanagement: Agile Projekte entwickeln sich kontinuierlich weiter und erfordern daher flexible Anpassungsmöglichkeiten. Sie sollten eine anpassbare Plattform wählen – zum Beispiel durch Drag-and-Drop-Funktionen oder einfache Änderungen von Fälligkeitsdaten -, um diesen Herausforderungen gerecht zu werden.
- Vorlagen zur Vereinfachung: Eine Arbeitsmanagementplattform mit vorgefertigten Vorlagen erleichtert den Einstieg und die Verwaltung ihrer Projekte enorm. Sie sparen Zeit und Mühe bei der Erstellung von Vorlagen von Grund auf neu. Zudem können sie diese Vorlagen an ihre individuellen Bedürfnisse anpassen.
- Kollaboration leicht gemacht: Ein agiles Team arbeitet während des gesamten Projekts eng zusammen – besonders wenn es darum geht, ein Epic anzugehen oder User Stories nach Priorität festzulegen. Nehmen wir Miro als Beispiel: Mit unserem digitalen Arbeitsbereich können agile Teams problemlos von überall aus zusammenarbeiten.
2. Namensgebung für das Epic
Um mit der detaillierten Planung des Epics zu beginnen, müssen sie diesem einen eindeutigen und prägnanten Titel geben. Dadurch wird sichergestellt, dass ihr Epic den strategischen Zielen entspricht und dem agilen Team Klarheit verschafft. Hier ist ein Beispiel, um dies zu verdeutlichen: Angenommen, ein App-Entwicklungsteam arbeitet an einer neuen mobilen App. Das Ziel dieser App ist es, die Kundenzufriedenheit zu steigern und dadurch höhere Umsätze zu erzielen. Der Titel dieses Epics könnte folgendermaßen aussehen: “Erstellung einer mobilen App zur Verbesserung des Kundenerlebnisses und Steigerung der Umsätze.” Dieser Titel gibt dem Projektteam eine klare Vorstellung davon, was sie mit diesem Epic erreichen sollen (Verbesserung des Kundenerlebnisses) und wie es zum Unternehmensziel beiträgt (Steigerung der Umsätze). Durch das Schreiben von User Stories kann das Projektteam sicherstellen, dass diese mit den Zielen des Epics übereinstimmen.
3. Bestimmung des Umgangs
Der Umfang des Epics legt fest, was sie erreichen möchten, warum dies wichtig für das Unternehmen ist und wie sie den Erfolg messen möchten. Er stellt auch Grenzen auf, die dem Team helfen sollen zu verstehen, welche Arbeit geplant ist. Wenn wir wieder das Beispiel der Entwicklung einer App nehmen: Der Umfang dieses Epics könnte folgende Informationen enthalten:
- Ziele: Was genau sie mit diesem Epic erreichen wolleb; warum es für das Unternehmen wichtig ist; wie lange es dauern soll.
- Wichtige Ergebnisse: Was das Hauptergebnis dieses Epics sein wird. Im Falle der App-Entwicklung wäre es die Entwicklung und Markteinführung einer erfolgreichen App.
- Akzeptanzkriterien: Wie sie den Erfolg dieses Epics definieren, zum Beispiel wenn bestimmte Funktionen live sind und einwandfrei funktionieren. Später werden wir genauer darauf eingehen, wie man Akzeptanzkriterien formuliert.
- Annahmen: Dinge, von denen sie aufgrund des Kundenfeedbacks glauben, dass sie wahr sind. Zum Beispiel könnte eine Marktforschung ergeben haben, dass Benutzer eine Suchleiste in deiner App wünschen.
- Einschränkungen: Alle Hindernisse oder Begrenzungen, die sie daran hindern könnten, die Arbeit zu erledigen – etwa Budgetbeschränkungen oder fehlende Ressourcen.
- Außerhalb des Umfangs: Um klare Grenzen zu setzen können sie auch beschreiben welche Arbeiten nicht Teil des Arbeitsumfangs sind.
Dies hilft dem Team sich auf die Aufgaben mit höchstem Nutzen zu konzentrieren und behält gleichzeitig im Blick was in Zukunft eventuell noch abgedeckt werden kann. Du kannst beispielsweise bestimmte Funktionen für zukünftige Epic-Projekte berücksichtigen aber diese müssen nicht unbedingt Teil dieses speziellen Epos sein. Eine Projektumfang-Vorlage kann dir helfen einen klaren und präzisen Umfang für dein Epic festzulegen.
4. Definieren von Abnahmekriterien
Die Abnahmekriterien eines agilen Epics legen fest, wann ein Arbeitsschritt als abgeschlossen gilt und alle Anforderungen des Endbenutzers erfüllt sind. Bei den Abnahmekriterien gibt es keine Grauzone – entweder sie werden erfüllt oder nicht. Verwende beim Formulieren der Akzeptanzkriterien eine klare und einfache Sprache, ähnlich wie ihr Kunde seine ideale Funktion beschreiben würde. So können sie leicht feststellen, ob die Kriterien erfüllt wurden. Hier sind einige Beispiele für Akzeptanzkriterien bei der Entwicklung einer mobilen App:
- Benutzer können über die App einen Kauf tätigen
- Benutzer können über die App Kontakt mit uns aufnehmen
- Benutzer können in unserer Suchleiste nach bestimmten Produkten oder Funktionen suchen
Die Kriterien sollten sich auf konkrete Funktionalitäten beziehen, nicht darauf, wie sie diese zu nutzen haben. Zum Beispiel: “Benutzer können über die App einkaufen” statt “Benutzer legen Artikel einfach in ihren Warenkorb”. Wenn sie dieses Format befolgen, können sie sicherstellen, dass ihre User Story erfolgreich abgeschlossen wurde, indem sie genau diese spezifische Funktionalität bereitstellen. Wenn sie Hilfe beim Schreiben ihrer Akzeptanzkriterien benötigen, kann ihnen Richard Kasparowskis Vorlage für User Stories als Leitfaden dienen.
5. Aufteilung des Epics in User Storys
In diesem Stadium ist die Phase des Erstellens von Epics abgeschlossen. Nun können sie das Epic in einzelne User Stories aufteilen und sie zu ihrem Product Backlog hinzufügen. Es gibt verschiedene Möglichkeiten, ein Epic in User Stories zu unterteilen; dabei ist Storytelling am gängigsten. Ein Tool zum Mapping von User Stories hilft Teams dabei, die Ereignisse des Epics visuell darzustellen. Hier sind einige Möglichkeiten, dies zu tun:
- Workflow-Aufschlüsselung: Das Epic wird basierend auf den einzelnen Arbeitsschritten unterteilt. Bei einer App-Entwicklung könnten diese Schritte z.B. das Erstellen eines Wireframes oder Optimieren der Benutzererfahrung beinhalten. Der Product Owner priorisiert dann diese Schritte je nach Wert für die Kunden.
- Aufteilung nach Rollen: Jedes Epic umfasst verschiedene Rollen, die an der Umsetzung beteiligt sind – etwa UX-Designer und Softwareentwickler. Sie können diese Rollen verwenden, um ihre User Stories zu kategorisieren und so das Epic weiter aufzuteilen.
Neben dem Storytelling gibt es auch andere Möglichkeiten ein Epic aufzuteilen:
- Nach Datenbegrenzung: Teilen sie das Epic in einzelne Funktionsbereiche basierend auf definierten Datengrenzen; bei einer mobilen App könnte man Funktionen wie “Kauf tätigen”, “Kontakt herstellen” oder “Information hochladen” als separate User Stories betrachten.
- Nach operationeller Begrenzung: Reduzieren sie das Epic zunächst auf eine praktikable Mindestanzahl von Funktionen und erweitere es dann mit zusätzlichen Features; bei einer App Entwicklung beginnen sie vielleicht damit, dass die Kernfunktionalität nutzbar ist und fügen später weitere Funktionselemente hinzu.
- Nicht-funktionale Anforderungen: Unterteilen sie das Epic in separate User Storys zur Erfüllung nicht funktionaler Anforderungen wie Leistungsfähigkeit, Skalierbarkeit und Sicherheit; bei einer neuen App könnten sie separate User Stories für Leistungstests, Sicherheitsaudits und Lasttests erstellen.
Es gibt keinen richtigen Weg, ein Epic aufzuteilen – es hängt alles von den Anforderungen des Kunden und dem Team ab. Manche Teams bevorzugen eine Visualisierung ihres gesamten Workflows, während andere von einer Aufteilung nach Datengrenzen profitieren.
6. Teile das Epic mit
Der Product Owner teilt das fertige Epic mit relevanten Stakeholdern wie z.B. Kundinnen oder Investorinnen, um deren Zustimmung zu erhalten und sicherzusicherzustellen, dassstellen dass alle Beteiligten an Bord sind. Danach wird es dem Projektteam zur Überprüfung und zum Feedback vorgelegt.
7. Anpassung und Aktualisierung des Backlogs nach jedem Sprint
Nachdem die Sprints abgeschlossen sind, nehmen sich die agilen Teams Zeit, um zu reflektieren, was gut funktioniert hat und welche Bereiche in Zukunft verbessert werden können. Während dieses Prozesses wird das Backlog überarbeitet, um sicherzustellen, dass die User Stories weiterhin relevant bleiben. Sie können dabei dem Prozess des Backlog Refinements folgen. Wenn festgestellt wird, dass Anpassungen notwendig sind, haben sie die Möglichkeit Elemente zu verschieben oder neue User Stories hinzuzufügen. Das Ziel ist es stets den Kunden so viel Wert wie möglich zu liefern.
Vielfältige Einsatzmöglichkeiten von Epics
Es existiert keine allgemeingültige Methode zur Verwendung von Epics. Daher ist es ratsam, mit gesundem Menschenverstand vorzugehen. Im Folgenden finden Sie einige Anwendungsbeispiele:
- Entwicklung eines umfangreichen (Teil-)Produkts. Bei der Entwicklung eines Produkts oder einer Dienstleistung besteht in der Regel aus mehreren Komponenten. Wenn sie etwa ein Schulungskurs erstellen, müssen sie Folien, z.B. Serious Games und Werbematerialien entwickeln. In diesem Fall bietet es sich an, das Epic in kleinere Teile zu zerlegen. Das Epic sollte alle Elemente enthalten, die am Ende zusammengefügt werden müssen, um das gewünschte Endergebnis zu erzielen.
- Phaseneinteilung des Projekts. Mithilfe von Epics können Projekte in klar definierte Phasen unterteilt werden. Jede Phase erhält dabei ihr eigenes Epic zugewiesen. Nehmen wir unter anderem eine Hochzeitsplanung als Projekt: Es gibt große Arbeitsabschnitte wie Vorbereitung, Hochzeitstag und den darauffolgenden Morgen. Innerhalb jeder Phase sind verschiedene Schritte erforderlich und involvieren, unterschiedliche Teammitglieder – sie tragen jedoch alle zum übergeordneten Ziel dieser jeweiligen Phase bei und sollten daher als User Stories betrachtet werden können; so erhalten Stakeholder einen klaren Überblick über den Fortschritt des Projekts.
- Einblicke in Abläufe oder Prozesse gewinnen, die aus verschiedenen Schritten bestehen. Epics können auch genutzt werden, um Prozesse innerhalb einer Organisation zu erfassen. Die einzelnen Schritte dieser Prozesse werden dann als User Stories betrachtet, die nacheinander ablaufen. Nehmen wir an, es wird eine Marketingkampagne für ein neues Produkt durchgeführt: Diese könnte in Teaser-Einführungen, Online-Produktpräsentationen, Blogs sowie Mailings und Folgemaßnahmen unterteilt werden.
- Betrachten Sie ein zu entwickelndes Produkt oder eine Dienstleistung aus der Perspektive verschiedener Endnutzer. Ein zu entwickelndes Produkt kann basierend auf den Wünschen und dem Wert verschiedener Endnutzer beschrieben werden. Dies ermöglicht einen Fokus auf die Funktionen des Produkts, die aus Sicht dieser Nutzergruppen wichtig sind. Um ein besseres Verständnis dafür zu bekommen, was diesen Nutzern wichtig ist, kann es hilfreich sein, mit Personas (fiktiven Personen, die detailliert beschrieben werden)zu arbeiten, die repräsentativ für diese Zielgruppe sind.
Wir haben bereits das “große Ganze” kennengelernt – die Epic – welche das übergeordnete Ziel darstellt, auf welches alle User-Stories hinarbeiten. Außerdem haben wir uns damit auseinandergesetzt, wann und wie Epics verwendet werden, sodass Sie nun selbst davon profitieren können.Wie bei vielen anderen Aspekten der agilen Welt gilt auch hier: Einfach loslegen! Viel Erfolg beim Einsatz Ihrer Epics!
Epics geben den User Stories Struktur und Bedeutung
Bevor man sich tatsächlich mit einem Epic befasst, muss dieses verfeinert werden. Verfeinern bedeutet, in Details zu gehen und gleichzeitig zu große Arbeitsabschnitte aufzuteilen.Das Ergebnis sind kleinere Abschnitte, die als User Stories betrachtet werden. In einigen Fällen müssen diese dann weiter unterteilt werden, um den richtigen Fokus auf das Ziel sicherzustellen.Durch die Ableitung der User-Stories aus demselben Epic wird sichergestellt, dass sich Teams über mehrere Iterationen hinweg einem größeren Ziel annähern und jedes Mal einen Mehrwert liefern. Dadurch wird gewährleistet, dass in jedem Sprint sichtbarer Fortschritt erzielt wird.
- Sie dienen als Leitfaden und Kontext für die Entwicklung jeder einzelnen User Story.
- Helfen, die Richtung des Projekts zu behalten und das “große Ganze” im Auge zu haben.
Scrum Master oder Agile Coach gesucht?
Scrum Training zum Scrum Master und Product Owner
Scrum Schulung – Scrum Master & Product Owner
PURE Consultant
Das Team der PURE Consultant hat ihren Themenfokus auf den Themen Projektmanagement und Prozessmanagement. Sollten Sie Bedarf oder Interesse an einer Projektmanagement Beratung, Prozessmanagement Beratung, Scrum Beratung oder PMO Beratung haben, so sprechen Sie uns an. Gemeinsam erarbeiten wir mit Ihnen die maßgeschneiderte Form der Zusammenarbeit und Ihr starker Partner an Ihrer Seite.
Gerne unterstützen wir Sie auch mit der passenden Scrum Schulung, verschaffen Sie sich gern einen Überblick über das für Sie passende Scrum Training.