Een Epic is een user story die niet binnen één sprint te ontwikkelen is, is een vuistregel die veel projecten hanteren om Epics te identificeren. Als je het mij vraagt ben je dan eigenlijk net te laat en mis je heel veel aspecten van een Epic waarmee je effectief je backlog en dus de ontwikkeling van je product kan managen.

Met Epics kan je veel meer dan alleen maar aangeven dat het om een story gaat die niet past in één sprint. Met behulp van Epics kun je bijvoorbeeld je stakeholders betrekken in hoe je de productontwikkeling gaat faseren, hoe je het product kan koppelen aan architectuur maar ook de voortgang van je product. 

Epics als grote stories

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.

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. 

Functional Epics

Epics op basis van stappen in de Customer Journey

Customer Journeys , of story mapping is een andere methode waarmee je relatief makkelijk je scope kan opdelen in brokken van gerelateerde functionaliteit. Daarmee zorg je er ook direct voor dat inzichtelijk wordt hoe je Epics bijdragen aan de impact op de klant. En kan je dus heel gericht de onderliggende stories en requirements vinden.

Epics op basis van customer Journey map

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.

Architectuur epics

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

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

Blog

Thuiswerk tips

Thuiswerk tips

Thuis werken hoe doe je dat eigenlijk?   Door Corona werken we tegenwoordig allemaal vaker thuis en is thuiswerken bijna de norm. Op de lange termijn is de verwachting dat thuiswerken onderdeel van de norm wordt. Daarom is het van belang om er voor te zorgen dat...

10 Tips voor de perfecte User Story

10 Tips voor de perfecte User Story

Als een gebruiker X wil ik zus en zo kunnen zodat ik dit en dat kan bereiken, is toch al bijna de perfecte User Story? Veel mensen denken dat een User Story alleen bestaat uit bovenstaande zinsconstructie. En dat gebruik van die zinsconstructie voldoende is om er voor...

De 5 meest voorkomende soorten automatisering

De 5 meest voorkomende soorten automatisering

Automatisering kan veel verschillende vormen aannemen, misschien is dat ook wel de reden dat er zo veel automatiseringsprojecten mislukken. Simpelweg omdat men elkaar niet begrijpt of omdat men denkt het over hetzelfde te hebben. Vaak gaat het over het automatiseren...

Top 3 boeken voor Business Consultants

Top 3 boeken voor Business Consultants

Helping, How to offer, Give and Receive Help De meest fundamentele vaardigheid van een Business Consultant is weten hoe je de klant het beste kan helpen. Niet op basis van de inhoud, maar door echt door te dringen tot de kern van het probleem. Helping, van Edgar...