Epic
Mit Epic werden die Anforderungen an eine neue Software beschrieben. Wie auch bei der User Story wird dabei eine alltägliche Sprache verwendet, also eine Sprache, die auch Nicht-Techniker verstehen können. Hintergrund dafür ist der Ansatz, Epic und User Story durch den Kunden erstellen zu lassen, der nicht technikaffin sein muss.
Allgemeine Informationen zum Thema
Epic kommt unter anderem in der agilen Softwareentwicklung – beispielsweise bei Scrum – vor. Dabei dient es zur Hilfe bei der Entwicklung von Product Backlogs und soll unterstützend bei der Übersichtsdarstellung neuer Produktanforderungen wirken. Ein Bestandteil von Epic ist die Story-Zerlegung, bei der es um die bessere Darstellung geht. Hierbei werden Übersichtsbeschreibungen in Detailbeschreibungen zerlegt, sodass die Umsetzung des Projektes erleichtert wird[1].
Unterscheidung zwischen Epics, User Stories und Themes
Die Unterscheidung zwischen User Story und Epics ist nicht genau festgelegt. Eine User Story beschreibt in Alltagssprache, was der Nutzer bzw. Kunde will. In aller Regel besteht diese User Story nur aus wenigen Worten oder einem Satz.
Der Übergang von User Stories zu Epics ist also fließend und kann nicht präzise definiert werden. Man spricht von einer „großen Story“, wenn man Epics meint, also eine Story, die groß genug ist, um zerlegt zu werden. Letztlich kommt es zur Verwendung von Epics, wenn die User Story mit wenigen Worten oder einem Satz nicht mehr zusammengefasst werden kann. Diese für eine User Story zu große Komplexität führt zum Übergang zu Epics.
Unter Themes versteht man hingegen Gruppen von User Storys, die einem bestimmten Thema zugeordnet werden. Wendet man einen Vergleich an, könnte man Themes mit Filmen vergleichen, etwa speziell mit James-Bond-Filmen, die eine Einordnung unter dem Oberbegriff „Filme“ erleichtern. Das Theme „James Bond“ führt hier zu einer Abgrenzung bzw. Präzisierung des Films und seinem Oberbegriff[2].
Beispiel für ein Epic
Stellt sich im Zuge einer Frage (auch Requirement genannt) heraus, dass zu viele Aspekte offen oder unklar sind bzw. eine Untergliederung nötig machen, kommt es zur Aufteilung in User Stories. Gleiches gilt, wenn das Requirement nicht in einen Sprint passt. In diesem Fall ergibt sich aus dem Requirement das Epic.
Da es bei der agilen Softwareentwicklung immer auch um Schätzungen geht, ist die Aufteilung in Storys wichtig, weil andernfalls das Development Team Probleme beim Schätzen des Aufwandes bekommt. Diese Probleme übertragen sich dann auch auf den Product Owner und das Management. Wenn Probleme also zerlegt und somit kleiner, überschaubarer gemacht werden, fallen Schätzungen leichter, die Planung kann auf längere Sicht besser funktionieren. Dazu ein Beispiel:
- Epic: Erstelle drei GUI‘s für Overview, dazu Detail und Login.
- User Story 1: Erstelle ein Overview GUI
- User Story 2: Erstelle ein Detail GUI
- User Story 3: Erstelle ein Login GUI.
Die Unterteilung von User Storys und Epics hat folgende Vorteile:
- Man zerlegt ein Problem in mehrere kleinere Probleme und kann so bessere Schätzungen abgeben.
- Der Task Breakdown wird erleichtert oder kann im besten Fall vollständig wegfallen.
- Das Business wird mit jeder User Story mit einem Value ausgestattet.
- Jede Story muss lediglich ein Problem lösen. Als endgültig abgeschlossen gilt die Aufgabe jedoch erst, wenn alle Stories fehlerfrei sind. Vorher erfolgt kein „Done“[3].
Die Formulierungen von Epics und User Stories
Sowohl für Epics als auch für User Stories gilt folgendes Schema, das sich als hilfreich und effizient erwiesen hat:
- Als wer (also Akteur, Kunde, Rolle) will ich was (also Inhalt, Bedarf, Ziel), damit warum (also der Nutzen, Wunsch, Gewinn, Vorteil) funktioniert.
Dieses Beschreibungsmuster, das auf W-Fragen basiert, ist effektiv, verständlich und wirkt unterstützend bei der Formulierung von unterschiedlichen Nutzern bzw. Kunden in der Alltagssprache. Die Anforderungen selbst richten sich nach der Art des Projektes und können dementsprechend sowohl Produkt- als auch Dienstleistungsanforderungen sein. Primär geht es um die gute Verständlichkeit, das Zerlegen in User Stories soll diese Verständlichkeit unterstreichen und verstärken. Dabei werden die Anforderungen schrittweise zerlegt und verfeinert, die User Stories bilden die Basis für das Gespräch der Beteiligten.
Für die praktische Anwendung bieten sich folgende Methoden und Hilfsmittel an:
- Die Arbeit mit Erhebungskarten oder Story Cards
- Die Durchführung von Kunden- oder Anwenderinterviews
- Die Durchführung von Fokusgruppenmeetings
- Die Veranstaltung von Anwendermeetings und Workshops
- Der Einsatz von Fragebögen
- Die Einbeziehung von Dokumentenanalysen
- Die Modellierung, also etwa Prototyping
Nicht jedes Hilfsmittel muss angewendet werden, was am sinnvollsten ist, hängt von der Art und der Größe des Projektes ab und davon, welche Methoden und Hilfsmittel die Beteiligten bevorzugen[4].
Bedeutung für das Development
In der agilen Softwareentwicklung sind sowohl User Stories und Epics erstens wichtiger Bestandteil für die erfolgreiche Arbeit und zweitens meist eng miteinander verbunden. Epics helfen, Strukturen zu schaffen, die die Projektplanung erleichtern und zu schnelleren und besseren Ergebnissen führen.
Einzelnachweise
- ↑ Epic Anforderungsmanagement de.wikipedia.org. Abgerufen am 27.03.2018
- ↑ User Stories Epics Themes scrumakademie.de. Abgerufen am 27.03.2018
- ↑ Scrum Epic Stories Tasks kusar.ch. Abgerufen am 27.03.2018
- ↑ Anforderungsmanagement in Scrum gotscharek-company.com. Abgerufen am 27.03.2018