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

De 5 Best gelezen artikelen op Virtual BA

De 5 Best gelezen artikelen op Virtual BA

Het jaar is alweer bijna ten einde, mooi moment om even stil te staan bij de best gelezen artikelen op www.virtualba.nl   Scopafijth - klinkt een beetje K maar de beste manier om Digitale en Business impact te bepalen De 4 stappen van een goede Business Analyse...

Virtual BA – Update

Aanmelden Virtual BA - Update Met de Virtual BA Update blijf je op de hoogte over de nieuwste blogs, artikelen en andere tips op Virtual BA. De Nieuwsbrief verschijnt ongeveer 1x per maand en je kan het op elk moment opzeggen. Je gegevens worden alleen gebruikt voor...

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...