Een epic kan worden gedefinieerd als een groot stuk werk met één gemeenschappelijk doel. Dit kan een functie, klantverzoek of zakelijke vereiste zijn. Het is een tijdelijke aanduiding voor een vereiste item met een paar beschrijvingen. Een epic is in principe één grote user story die vaak niet in één sprint kan worden uitgevoerd. Daarom wordt deze epic in kleinere blokjes gehakt en komen onder deze epic verschillende user stories te staan. Door telkens enkele user stories toe te voegen aan de sprint backlog kan het gemeenschappelijke doel (de epic) na een paar sprints behaald worden, of in Scrum taal als “done” worden gedefinieerd.

Epic in relatie tot een roadmap, feature & user story

Een epic komt voort uit een roadmap wat een afgeleide is van de productvisie. Een roadmap is een visuele weergave van wat je wilt bereiken. Het geeft op hoofdlijnen weer hoe je de productvisie gaat realiseren. Deze hoofdlijnen beschrijf je in zogenaamde epic’s, grote stappen om tot je productdoel te komen. De epic’s zijn abstract en beschrijven functioneel de onderwerpen die je gaat aanpakken. Hieronder wordt de relatie van de epic naar user story beschreven:

  • Epic: een hoofdonderwerp of thema waar enkele kwartalen of zelfs jaren aan gewerkt kan worden. Bijvoorbeeld: je doel is een boodschappen app ontwerpen, dan is de ‘assortimentslijst’ een epic.

  • Feature: een onderdeel (functionaliteit) van een epic waar één of enkele sprints aan gewerkt kan worden en dat binnen een kwartaal gerealiseerd kan worden. Een feature binnen de epic ‘assortimentslijst’ is het ‘sorteren op alfabet’ of het ‘filteren op productcategorie’.

  • Product Backlog Item (PBI): een deel van een feature dat klein genoeg is om in een sprint opgepakt te worden. Een PBI kan zeer uiteenlopende vormen hebben; een korte tekst, een verwijzing naar een voorbeeld, een grafisch ontwerp dat is gemaakt, et cetera. Voor de feature ‘filteren op productcategorie’ is er een PBI voor het ‘opslaan en filteren van de categorieën’, het ‘onthouden van de filtering tijdens de sessie’ en een PBI voor het ‘het opslaan van de filtering in het account’.

  • User story: de user story is een gestructureerde manier om een PBI te schrijven vanuit de behoefte van de gebruiker, inclusief de waarde die wordt geleverd. De term PBI en user story worden in de praktijk nogal eens door elkaar gebruikt; de vorm van een user story komt veel voor. Vaak is dat vormgegeven in de vorm ‘ALS … WIL IK … ZODAT …’ Voor een feature ‘filteren op productcategorie’ zou dit kunnen zijn: ALS online shopper WIL IK het assortiment kunnen filteren ZODAT ik direct de aanbiedingen kan zien. Een andere user story kan zijn: ALS online shopper WIL IK het assortiment kunnen filteren ZODAT alle artikelen van de kaasafdeling tegelijk inzichtelijk worden om makkelijk te kunnen bestellen.
  • Task: dit is de kleinst mogelijke opsplitsing in delen. Binnen het team worden de PBIs of user stories uitgeschreven in concrete taken die door een teamlid binnen de sprint worden opgepakt. Een task heeft een maximale inspanning van een halve werkdag, maar dit kan dus ook een kwartier zijn. Een voorbeeld kan zijn ‘dropdownlijst categorieën rechtsboven plaatsen’ of ‘dropdownlijst vullen met categorieën uit de database’.

De vuistregel is, als er meer dan 5 user stories zijn van hetzelfde focusgebied in een project, dan is het goed om een epic te maken en alle vijf die user stories aan die Epic toe te voegen.

Waarom is Epic belangrijk?

Als je de roadmap goed weet op te splitsen in onderwerpen en thema’s (epics) en dit weet op te delen in features, kun je mensen meenemen in de inhoud. Ze gaan het beter begrijpen, omdat de verbanden en onderlinge relaties helder worden. Epic is ook een goede manier om de voortgang van een complexe feature bij te houden. Zo waarborg je welke user stories bijdragen bij het behalen van een specifiek doel. Dit helpt het Scrum team om op een effectievere manier de product backlog items te prioriteren. Aangezien epic slechts een tijdelijke aanduiding is, kunnen user stories uit een epic worden verdeeld over meerdere projecten. Normaliter zijn er een paar sprints nodig om een epic te voltooien. Product owners kunnen eenvoudig het voltooiingspercentage van een epic berekenen door te kijken hoeveel procent van de user stories voltooid zijn.

Hoe kijken wij naar Epic?

Met tientallen projecten aan ervaring gebruiken we zelf graag het volgende format om een epic goed uit te werken naar user stories zodat deze overzichtelijk zijn voor het ontwikkelteam. Tegelijkertijd kunnen we met deze ‘one-pager’ richting andere stakeholders controleren of hun verwachtingen goed worden vertaald. We hebben hier een voorbeeld genomen voor een van onze klanten. In dit voorbeeld gaat het om het kunnen selecteren van een andere taal dan Nederlands voor de bezoeker van een webshop.

Note: we kennen situaties waarbij zeer succesvol is gewekt met job stories in plaats van user stories. In dit geval zijn we wel uitgegaan van user stories.

Voorbeeld van Epic
Voorbeeld van Epic 2

Het overzicht toont ons wie verantwoordelijk is voor de epic, wat het doel is, welke taken uitgevoerd moeten worden, de prioriteit van de user stories en in welke sprint deze worden uitgevoerd.

Burndown grafieken gebruiken we dan weer om een visuele weergave van epics te geven. Dit motiveert het development team en houdt de stakeholders op de hoogte. Het geeft een duidelijk overzicht van de vooruitgang dat het team maakt en waar er werk is toegevoegd en verwijderd door de product owner. Dit zorgt ervoor dat er transparantie is binnen het project en het team.

Wil je meer leren over epics en user stories, en jezelf verder ontwikkelen als product owner? Bekijk onze trainingen voor product owners.

Leer technieken waar je morgen mee aan de slag kan!

Trainen bij dé plek voor product owners. Kleine klassen & trainers met +10 jaar ervaring.