Agile epics: definitie, voorbeelden en sjablonen

Bij het toepassen van agile en DevOps is een epic bedoeld om taken te beheren. Een epic is een gedefinieerde hoeveelheid werk die is onderverdeeld in specifieke taken (story's of userstory's genoemd) op basis van de behoeften/wensen van klanten of eindgebruikers. Met een sjabloon voor het bijhouden van taken kunnen teams hun taken effectief organiseren, prioriteren en controleren.

Epics zijn een handige manier om je werk te organiseren en een hiërarchie te creëren. Het idee is om werk op te splitsen in leverbare stukken, zodat grote projecten daadwerkelijk kunnen worden gedaan en je regelmatig waarde aan de klanten kunt blijven aanbieden. Epics helpen teams hun werk op te splitsen, terwijl ze blijven werken aan een groter doel.

Om ook bij het organiseren van grote taken, zoals epics, agile te blijven, is geen kleinigheid. Leren hoe epics zich verhouden tot best practices voor agile en DevOps is een essentiële vaardigheid, ongeacht de grootte van de organisatie.

Een epic is een grote hoeveelheid werk die kan worden opgesplitst in een aantal kleinere story's, ook wel 'issues' genoemd in Jira. Bij epics zijn vaak meerdere teams betrokken, in meerdere projecten, en deze epics kunnen zelfs op meerdere borden worden gevolgd.

Epics worden bijna altijd geleverd via een set sprints. Naarmate een team meer leert over een epic door ontwikkeling en feedback van klanten, worden er zo nodig userstory's toegevoegd en verwijderd. Dat is de essentie van agile epics: de scope is flexibel, gebaseerd op feedback van klanten en de teamcadans.

Stel, het is 2050 en we werken voor een organisatie die ruimtereizen organiseert voor toeristen. We doen een stuk of twaalf lanceringen per jaar, dus het is niet zo dat elke lancering een ultieme uitdaging is, maar het is nog steeds geen routinewerk en er zijn heel wat arbeidsuren nodig om een lancering te voltooien. Dit is precies goed voor een epic.

Een voorbeeld van een epic, 'Lancering toeristische ruimtevlucht maart 2050', bevat story's over routinematige werkitems naast story's die zijn gericht op het verbeteren van de belangrijkste aspecten van de lancering van de shuttle, van klanten die tickets kopen voor een ruimtereis tot de lancering van de raket zelf. Als zodanig zullen meerdere teams bijdragen aan deze epic door te werken aan een breed scala aan story's.

Het softwareteam dat de aankoop van tickets voor de lancering van maart 2050 ondersteunt, zou hun epic als volgt kunnen structureren:

Tegelijkertijd kunnen de voortstuwingsteams met onderstaande story's bijdragen aan dezelfde epic:

Een epic moet het ontwikkelingsteam alles geven wat ze nodig hebben om succesvol te zijn. Vanuit praktisch perspectief vertegenwoordigt een epic het hoogste niveau van hun werkhiërarchie. Het begrijpen van hoe een epic zich verhoudt tot andere agile structuren biedt echter een belangrijke context voor het dagelijkse ontwikkelwerk.

• Een productroadmap is een actieplan voor hoe een product of oplossing in de loop van de tijd zal evolueren.
• Een thema is een organisatiedoel dat het maken van epics en initiatieven stimuleert.
• De roadmap van het product wordt uitgedrukt en gevisualiseerd als een reeks initiatieven die langs een tijdlijn worden uitgezet.
• Het opsplitsen van initiatieven in epics helpt om het dagelijkse werk van het team, uitgedrukt in kleinere story's, dicht bij de algemene bedrijfsdoelen te houden.

Een reeks voltooide epics vormt de ruggengraat van een specifiek initiatief, waardoor het algehele product zich blijft ontwikkelen en evolueren op basis van de vraag van de markt en de klant, naast organisatorische thema's.

Uit ons voorbeeld hierboven zou het verhogen van het aantal lanceringen van de spaceshuttle een thema kunnen zijn. De roadmap moet er dan op gericht zijn om het aantal lanceringen te verhogen van 3 per kwartaal naar 4. De initiatieven zouden zijn het verlagen van de kosten en het verhogen van de kaartverkoop. De verschillende epics cumuleren uiteindelijk in de initiatieven.

Houd bij het aanmaken van een nieuwe epic rekening met andere plannings- en organisatietools die je team mogelijk al gebruikt. Het opstellen van epics op basis van de kwartaaldoelen of OKR's van een team is een goed begin. Houd bij het maken van een epic rekening met het volgende:

• Rapportage maak epics voor de projecten die managers en leidinggevenden in de gaten willen houden.
• Storytelling: gebruik epics en de story's die hieronder vallen als een mechanisme om het verhaal te vertellen over hoe je tot de huidige staat van een functie of product bent gekomen.
• Cultuur: laat de organisatiecultuur de omvang en granulariteit van een epic bepalen.
• Tijd: de meeste ontwikkelingsteams vertrouwen op schattingskaders in plaats van tijd, maar het kan absoluut geen kwaad ervoor te zorgen dat je epics een paar weken nodig hebben om te voltooien. Niet te lang en niet te kort.

Bekijk hoe epics werken in Jira.

Het opsplitsen van een epic in meer praktische story's helpt bij het begrijpen van een project en het behouden van momentum, maar het kan een ontmoedigende taak zijn voor niet-ingewijden. Er is geen universele oplossing voor het maken van story's uit een epic, maar er zijn veel goede opties om te overwegen:

• Gebruikersrol of persona: schrijf een unieke story voor elke gebruikerspersona. 'Snellere login voor nieuwe bezoekers', 'snellere login voor terugkerende klanten', enz.
• Geordende stappen: breek het proces op en maak voor elke stap een story.
• Cultuur: laat teamnormen bepalen of een story een snelle taak of een project van een week is.
• Tijd: tenzij er iets anders is afgesproken, is het belangrijk om story's te ontwerpen die in één sprint of minder kunnen worden voltooid.

Er is geen universele definitie die een grens trekt tussen een grote story en een epic. Over het algemeen moet elke scope van het werk waarvoor het team een voltooingstijd schat van 'weken' (of langer), in plaats van 'uren' of 'dagen', worden beschouwd als een epic en worden opgesplitst in kleinere story's.

Burndown-grafieken kunnen worden gebruikt om epics te visualiseren en hebben als doel teams gemotiveerd te houden en de uitvoerende belanghebbenden te informeren. Een goede burndown-grafiek van een epic is waar de agility van de organisatie echt tot zijn recht komt.

De burndown-grafiek van een epic toont de werkelijke en geschatte hoeveelheid werk die moet worden verricht in een sprint of epic. De horizontale x-as in een burndown-grafiek geeft de tijd aan en de verticale y-as story's of issues.

Gebruik een burndown-grafiek om het totale resterende werk bij te houden en om de kans op het behalen van het sprintdoel te voorspellen. Door het resterende werk gedurende de hele iteratie te volgen, kan een team de voortgang ervan beheren en dienovereenkomstig reageren.

Door een burndown-grafiek bij te houden, wordt duidelijk wat de vorderingen van het team zijn en waar de blockers zitten. Als deze datapunten duidelijk zichtbaar zijn, weten alle teamleden waar ze aan toe zijn en kan er een open discussie worden gevoerd over de evolutie van het product en afrondingsprognoses. En dat transparantie vertrouwen opbouwt, is natuurlijk ook zeer belangrijk.

Lees hier meer over het configureren van burndown-grafieken in Jira

Als je eenmaal de kunst van het aanmaken van epics en story's onder de knie hebt, wil je misschien nog een stap verder gaan en optimaliseren met behulp van automatisering. Dit zijn drie van de meest voorkomende automatiseringsregels die worden gebruikt voor sprints in Jira.

1. Automatisch drie story's toevoegen bij het maken van een epic. Ga naar de regel.
2. Story's automatisch sluiten wanneer de epic is gemarkeerd als voltooid. Ga naar de regel.
3. De status van een epic wijzigen wanneer de status van een van de gekoppelde issues verandert. Ga naar de regel.

Bekijk deze en nog honderden andere automatiseringsregels in de sjabloonbibliotheek van Jira Automation.

Naar de bibliotheek

Epics vormen niet de absolute basis van een agile programma, maar ze zijn de praktische drijfveren voor de meeste agile en DevOps-teams. Begrijpen waar ze passen in een gezond agile programma creëert context voor je werk, terwijl het opsplitsen in story's momentum creëert.