Om dat voor elkaar te krijgen is het van belang dat je al gaat nadenken over Epics op het moment dat je bezig bent met het bepalen van je scope en verzamelen van de user stories.

Hieronder een aantal methoden die je kan gebruiken om Epics te identificeren:

1. Epics als samenhangende functionele brokken die gezamenlijk (nagenoeg) het zelfde gebruikers doel hebben.
2. Epics als stappen in de customer journey, zodat je backlog direct gelinkt kan worden aan het effect voor de klant
3. Epics als Business Service zodat je je backlog kan linken aan de enterprise architectuur

Het voordeel van dit soort Epics is dat je ze heel gericht samen met je stakeholders kan vullen met stories op het moment dat je ze nodig hebt met precies die stakeholders die je nodig hebt voor dat type functionaliteit, scherm of Business Service.

De ervaring die je vervolgens opdoet met het ontwikkelen van die stories binnen die Epic kun je vervolgens gebruiken om betere voorspellingen te maken over de resterende stories binnen die Epic en misschien zelfs te versnellen. 

De samenhang tussen Epics kun je vervolgens mooi gebruiken om te laten zien hoever je bent in de roadmap scope etc.

Hoe identificeer je dan nu die Epics

Om Epics te identificeren zijn er verschillende technieken en tools, maar de meest basale is gewoon om de scope van je product onder te verdelen in verschillende logische brokken.
Kan je zo’n brok onderverdelen in kleinere stukjes dan heb je een Epic te pakken, lukt dat niet kijk dan of je die functionaliteit onder kan brengen in een andere Epic.

Natuurlijk is het voor de communicatie met je stakeholders wel practicer als de Epics ook iets betekenen of gerelateerd kunnen worden aan bepaalde (strategische) doelstellingen.

1. Epics op basis van Functionele brokken.
2. Epics op basis van Customer Journey stappen
3. Epics op basis van Enterprise architectuur.

Epics op basis van Functionele brokken.

Functionele brokken klinkt natuurlijk wel lekker makkelijk, maar hoe identificeer je nu een functionele brok. Een handige methode die je daarvoor kan gebruiken is UML. UML is wellicht een techniek uit de oude doos. Maar use cases en dan wellicht de smart use case methodologie van Sander Hoogendoorn is een relatief praktische methode waarmee je snel je scope kan onderverdelen in verschillende functionaliteiten (usecases) en die je gemakkelijk kan doorvertalen naar Epics. 

Epics op basis van stappen in de Customer Journey

Epics op basis van Enterprise Architectuur.

Enterprise architecturen, vooral die gebaseerd zijn op Archimate, zijn een perfecte basis op basis waarvan onderliggende user stories verzameld worden. Het voordeel van de architectuur aanpak is dat je direct ook aangesloten bent op de architectuur en impact buiten de architectuur snel kan identificeren.

Valkuilen van Epics

Het feit dat je je backlog indeelt in Epics betekent niet dat je je product Epic voor Epic moet gaan ontwikkelen, immers Epics zullen in de meeste gevallen een samenhangend gedeelte zijn van je waardeketen. Je waardeketen van je product is meestal een som van verschillende Epics.

Epic Hierarchy

Hierarchy klinkt misschien een beetje strikt maar op het moment dat je begint met het opdelen van Epics in meerdere user stories, gaat het je ook gebeuren dat je die onderverdeling weer kan groeperen in nieuwe Epics. Heb je dan een hele zuivere definitie over wat een Epic precies is, niet perse. Maar je hebt dan wel een structuur met een duidelijke samenhang tussen de verschillende functionaliteiten en dat is uiteindelijk waar het om gaat.

Hulp nodig?

Ben je bezig met het opstellen van een backlog en kom je er niet uit neem contact op met mij ( Arnoud Zeeuw van der Laan)  06-42 09 4875, ik help je graag verder. 

Goede Boeken

Populair

7 Fouten die veel Digitale en IT projecten maken
5 Soorten Automatisering
Automatiseren, Digitaliseren of Robotiseren
4 Stappen van een goede Business analyse
User Stories vs Requirements

Blog