Een epic is een groot gebruikersverhaal in Agile softwareontwikkeling dat een omvangrijke functionaliteit of een strategisch doel beschrijft dat te groot is om in één sprint te realiseren. Epics worden opgesplitst in kleinere, beheersbare eenheden — user stories — die het team vervolgens oppakt in de dagelijkse sprintplanning. Een softwarebedrijf dat een nieuw betaalsysteem bouwt, kan dit omschrijven als één epic: “Als gebruiker wil ik snel en veilig kunnen betalen.” Dat epic wordt vervolgens opgedeeld in stories als “betalen met creditcard”, “factuuroverzicht bekijken” en “terugboeking aanvragen”. Epics helpen teams om het grote plaatje te bewaken terwijl ze tegelijk in kleine stappen werken, en vormen daarmee de brug tussen de strategische productvisie en de dagelijkse sprintactiviteiten.
Epics in de Agile hiërarchie
Agile-frameworks kennen een hiërarchie van planningsniveaus die van groot naar klein loopt. Het begrijpen van deze hiërarchie helpt je om epics in de juiste context te plaatsen.
Van thema naar taak
- Thema’s of strategische doelen: de hoogste laag, beschrijft grote bedrijfsdoelstellingen zoals “internationalisering” of “mobiele ervaring verbeteren”.
- Epics: grote functies of capabilities die meerdere sprints beslaan en bijdragen aan een thema.
- User stories: concrete, kleine stukken functionaliteit die passen in één sprint en direct waarde leveren voor een gebruiker.
- Taken (tasks): de technische deelstappen die een ontwikkelaar uitvoert om een user story te realiseren.
In tools zoals Jira kun je deze hiërarchie letterlijk inrichten: epics zijn een apart issuetype waaraan meerdere stories zijn gekoppeld. In Trello, Linear of Azure DevOps zijn vergelijkbare structuren beschikbaar, al verschilt de terminologie soms.
Hoe schrijf je een goede epic?
Een epic begint als een brede beschrijving van een doel of functionaliteit, maar heeft genoeg detail om richting te geven aan de stories die eronder vallen. Een goede epic bevat typisch de volgende elementen:
Een duidelijke titel en beschrijving
De titel beschrijft de functionaliteit op hoog niveau. De beschrijving legt uit welk probleem de epic oplost, voor wie, en welke waarde dit oplevert. Gebruik bij voorkeur de standaard user story-opmaak als vertrekpunt: “Als [persona] wil ik [functionaliteit] zodat [doel of waarde].”
Acceptatiecriteria op epic-niveau
Epics krijgen globale acceptatiecriteria mee die beschrijven wanneer de epic als voltooid wordt beschouwd. Deze zijn bewust minder gedetailleerd dan de acceptatiecriteria van individuele stories en bieden ruimte voor verdere specificatie tijdens de refinement van de bijbehorende stories.
Een eigenaar en stakeholders
Elke epic heeft idealiter een duidelijke eigenaar — vaak de product owner of een specifieke stakeholder — die verantwoordelijk is voor de prioritering en afstemming. Stakeholders die betrokken zijn bij de acceptatie van de epic worden expliciet benoemd.
Tijdshorizon en prioriteit
Omdat epics meerdere sprints omvatten, geef je aan in welk kwartaal of welke release de epic wordt verwacht. Dit sluit aan bij de roadmap en helpt stakeholders om verwachtingen te managen.
Van epic naar user story: de refinement
Het opsplitsen van een epic in user stories is een vaardigheid die teams met oefening steeds beter beheersen. Het doel is stories te maken die voldoen aan de INVEST-criteria:
- Independent: de story kan onafhankelijk van andere stories worden gebouwd en getest.
- Negotiable: de details zijn nog bespreekbaar en niet in beton gegoten.
- Valuable: de story levert op zichzelf waarde voor een gebruiker of het systeem.
- Estimable: het team kan een schatting maken van de benodigde inspanning.
- Small: de story past comfortabel in één sprint.
- Testable: er zijn duidelijke criteria op basis waarvan je kunt vaststellen of de story klaar is.
Tijdens een backlog refinement-sessie bespreekt het team samen welke stories er uit een epic voortkomen, worden de stories geschat en wordt de prioriteit bepaald. Het is normaal dat een epic groeit of krimpt naarmate het team en de stakeholders meer inzicht krijgen in de vereisten.
Epics in de praktijk: veelgemaakte fouten
Teams die nieuw zijn met epics maken vaak een aantal herkenbare fouten.
Een epic is geen technisch projectplan
Een epic beschrijft wat en voor wie, niet hoe. Het is verleidelijk om een epic te schrijven als een technische specificatie of als een lijst van implementatiestappen, maar dat ondermijnt de gebruikersgerichte aanpak van Agile. Houd de beschrijving op het niveau van gebruikerswaarde.
Epics te vroeg volledig uitschrijven
Epics die ver in de toekomst liggen, hoef je nog niet volledig te specificeren. Te vroeg gedetailleerde epics leiden tot veel verspilde analyse-inspanning als prioriteiten later veranderen. Werk epics verder uit naarmate ze dichter bij de top van de roadmap komen.
Stories die te groot blijven
Als stories na de refinement nog steeds te groot zijn om in één sprint te passen, zijn het eigenlijk mini-epics. Splits ze verder op totdat ze echt binnen één sprint realiseerbaar zijn. Een vuistregel: een story mag maximaal de helft van de sprintcapaciteit vereisen.
Epics bijhouden en rapporteren
Omdat epics meerdere sprints beslaan, heb je een manier nodig om de voortgang bij te houden. De meeste Agile-tools bieden een epic burndown chart of epic board waarop je kunt zien hoeveel stories zijn afgerond, hoeveel er nog openstaan en of de epic op schema ligt.
In grotere organisaties worden epics vaak gevisualiseerd op een kwartaalroadmap of een program board (zoals in SAFe, het Scaled Agile Framework). Stakeholders kunnen hier in één oogopslag zien welke epics wanneer worden verwacht en hoe afhankelijkheden tussen teams worden beheerd.
Conclusie
Epics zijn een onmisbaar hulpmiddel in Agile-teams om grote functionaliteiten beheersbaar te maken zonder het overzicht over de strategische doelstellingen te verliezen. Ze vormen de brug tussen de productstrategie en het dagelijkse sprintwerk, en helpen zowel het team als stakeholders om verwachtingen te managen en prioriteiten te stellen. Schrijf epics vanuit het perspectief van de gebruiker, splits ze tijdig op in kleine, waardevolle stories en houd de voortgang actief bij in jouw Agile-tooling. Door epics goed toe te passen, verhoog je de voorspelbaarheid van jouw leveringsproces en houd je de focus op wat er echt toe doet: waarde leveren voor jouw gebruikers.
Veelgestelde vragen
- Hoe lang duurt een epic gemiddeld?
Een epic beslaat doorgaans twee tot zes sprints, wat neerkomt op één tot drie maanden bij tweewekelijkse sprints. Dit is echter geen vaste regel: sommige epics zijn binnen één sprint af als ze kleiner blijken te zijn dan verwacht, terwijl strategische epics soms een heel kwartaal of langer in beslag nemen. Als een epic structureel langer dan een kwartaal duurt, is het vaak een teken dat het beter opgesplitst kan worden in meerdere kleinere epics. - Wat is het verschil tussen een epic en een user story?
Een user story beschrijft een kleine, concrete functionaliteit die in één sprint kan worden gebouwd en getest. Een epic is een groter verhaal dat meerdere user stories omvat en meerdere sprints overspant. Je kunt een epic beschouwen als een container van gerelateerde user stories die samen een grotere gebruikersbehoefte of bedrijfsdoelstelling vervullen. De grenslijn is niet altijd scherp, maar de praktische test is: past het in één sprint? Dan is het een story. Past het niet? Dan is het een epic. - Hoe gebruik ik epics in Jira?
In Jira is een epic een apart issuetype dat je aanmaakt via de backlog of het roadmap-overzicht. Je kunt vervolgens user stories en bugs koppelen aan een epic via het “Epic Link”-veld (in oudere Jira-versies) of via de parent-relatie in nieuwere versies van Jira Software. Het epic board en de epic burndown chart in Jira geven inzicht in de voortgang per epic. In Jira kun je ook kleurcodes toewijzen aan epics zodat je in de sprintboard snel kunt zien welke stories bij welke epic horen. - Wie is verantwoordelijk voor het schrijven van epics?
De product owner is primair verantwoordelijk voor het definiëren en prioriteren van epics, maar in de praktijk is het schrijven van epics een gezamenlijk proces. Stakeholders, business analisten, UX-designers en het ontwikkelteam dragen allemaal bij aan het uitwerken van de epics tijdens discovery-sessies en refinements. De product owner heeft de uiteindelijke beslissing over prioriteit en acceptatiecriteria. - Kan een epic worden afgesloten zonder dat alle stories zijn voltooid?
Ja, dat kan. Soms blijkt tijdens de uitvoering dat bepaalde stories die oorspronkelijk aan een epic waren toegewezen, toch minder relevant zijn of kunnen worden verschoven naar een toekomstige epic. Een epic wordt gesloten wanneer de kern van de functionaliteit is geleverd en de gedefinieerde acceptatiecriteria zijn behaald, ook als er nog edge-case stories open staan. Die resterende stories worden dan opgenomen in de backlog of in een volgende epic voor verdere doorontwikkeling.