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.
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:
- Epics als samenhangende functionele brokken die gezamenlijk (nagenoeg) het zelfde gebruikers doel hebben.
- Epics als stappen in de customer journey, zodat je backlog direct gelinkt kan worden aan het effect voor de klant
- 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.
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 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
Blog
Omgaan met Wettelijke Requirements
u
Type Business Analyses
3 Situaties die baat hebben bij een Business Analyse In dit artikel leg ik uit in welke situaties een Business Analyse toegevoegde waarde biedt en waarom. Digitalisering van bedrijfsprocessen Integratie van verschillende systemen Introductie nieuw product of...
10 Tips for creating perfect User Stories
Often it is believed that a perfect User Story is written like: “As a user X I want to do Y So I can achieve Z”. Some people also believe that this is all what needs to be written down for a development team to create the right results. Therefore, it is not surprising...
De 5 soorten analisten in het Digitale/IT domein
Een ruit is een vlieger maar een vlieger is geen ruit, dit zei mijn wiskunde leraar vroeger altijd. Waarmee hij bedoelde dat vormen op elkaar kunnen lijken maar dat de eigenschappen verschillend zijn. Deze filosofie is ook van toepassing op een Business Analist,...
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...