Wat is voor ons een Epic? Minder lagen, meer duidelijkheid.

De discussie achter het label

Binnen een project waarin we volgens SAFe werken, ontstond discussie over wat voor ons een Epic is. De gezamenlijke richting: een Epic levert direct waarde voor de business of ondersteunt de technische of architectonische basis. Dat geeft richting, maar roept ook een vervolgvraag op: wanneer helpt de verdere indeling in Features en Capabilities, en wanneer voegt die vooral administratie toe?

Deze discussie is de aanleiding voor dit artikel. De beslisroute hieronder is een voorstel, geen verslag van stappen die het project al heeft gezet. Ook de voorbeelden zijn fictief.

Waarde verklaart waarom, schaal bepaalt het niveau

SAFe onderscheidt Business Epics, gericht op directe klantwaarde, en Enabler Epics, die toekomstige business- of technische behoeften mogelijk maken. Bij een Epic horen een substantiële verandering, een investeringsafweging en een toetsbare verwachting. De officiële beschrijving koppelt dit aan portfoliosturing, een Lean businesscase en een minimum viable product (MVP). [1]

Alleen “levert waarde” is dus onvoldoende: ook een kleine verbetering kan waardevol zijn. Evenmin is iedere technische taak een Enabler Epic. Enablers kunnen binnen SAFe op verschillende backlogniveaus voorkomen. Een beperkte aanpassing aan een testomgeving hoeft geen strategisch initiatief te worden. [2]

Een bruikbare lokale werkdefinitie zou zijn: een Epic beschrijft een samenhangende verandering met een expliciet beoogd resultaat, rechtstreeks voor gebruikers of via een noodzakelijke technische verbetering. Spreek daarnaast af welke omvang, onzekerheid of besluitbevoegdheid dit niveau rechtvaardigt. Leg vast hoe jullie werkdefinitie zich verhoudt tot de officiële SAFe-betekenis.

Zo kun je samen tot een besluit komen

Begin met echte backlogvoorbeelden en bespreek ze met business, Product Owner, architectuur, development en Quality Engineering. Kies zowel gebruikersfunctionaliteit als onderhoud en technische vernieuwing. Vraag per voorbeeld: wie heeft hier voordeel van, welk probleem lossen we op, welke onzekerheid onderzoeken we en wie beslist over de investering?

Neem een fictief initiatief om aanvragen sneller af te handelen. “Een nieuw scherm bouwen” beschrijft een oplossing. “Medewerkers hoeven gegevens minder vaak opnieuw in te voeren” beschrijft een verwachte verbetering. Spreek af hoe je die verwachting onderzoekt, bijvoorbeeld met een beperkte gebruikersgroep en observatie van het werkproces.

Voor een technische basis geldt dezelfde discipline. “De architectuur moderniseren” is te ruim. “Een gedeelde autorisatievoorziening realiseren zodat nieuwe diensten dezelfde toegangsregels kunnen toepassen” maakt de relatie met toekomstig werk concreet. Benoem ook het risico van niets doen en de kleinste bruikbare stap. Een technische oplevering is nog geen bewijs dat het beoogde effect is bereikt.

Capabilities weglaten is niet hetzelfde als Features weglaten

Een Feature verbindt een stakeholderbehoefte aan functionaliteit die een Agile Release Train (ART) binnen een Planning Interval (PI) kan leveren. Een Capability beschrijft grotere samenhang, vaak over meerdere ART’s. Die niveaus beantwoorden dus verschillende coördinatievragen. [3]

Essential SAFe werkt al met Features en Stories; een afzonderlijke Capability-laag is niet voor elke inrichting nodig. Geen Capabilities gebruiken kan daarom passen bij de gekozen SAFe-configuratie, zonder een afwijking te zijn. Features helemaal laten vervallen is een andere keuze: daarmee verander je een gebruikelijke schakel tussen ART-planning en teamwerk. [4]

Wanneer minder lagen kunnen helpen

Een lokale vereenvoudiging naar Epic en Stories kan het onderzoeken waard zijn wanneer één team een afgebakend product beheert, nauwelijks externe afhankelijkheden heeft en de tussenlaag geen eigen besluit ondersteunt. Hetzelfde geldt wanneer Epic en Feature consequent dezelfde beschrijving, eigenaar en status hebben. Dubbele registratie kan dan bespreektijd kosten zonder extra inzicht op te leveren.

Dat is een reden voor een experiment, geen bewijs dat Features overbodig zijn. Misschien zijn de Epics te klein gedefinieerd of wordt het Feature-niveau niet goed gebruikt. Verander daarom niet alleen het ticketschema. Leg vast waar voortaan prioriteit, acceptatie, PI-doelen en afhankelijkheden zichtbaar worden. Als een lokaal “Epic” feitelijk een Feature vervangt, maak die vertaling expliciet voor andere teams.

Behoud de tussenlaag wanneer meerdere teams samen een bruikbaar resultaat moeten leveren, afzonderlijke opleveringen prioriteit krijgen of afhankelijkheden anders verdwijnen in lange lijsten Stories. Contractuele afspraken en organisatiebrede rapportage kunnen eveneens een reden zijn om de bestaande indeling te behouden. Minder labels mogen geen minder duidelijke verantwoordelijkheden betekenen.

Maak de werkwijze zelf toetsbaar

Leg de keuze kort vast: welk probleem veroorzaakt de huidige indeling, wat laten we weg, welke afspraken nemen de functie over en wanneer evalueren we? Vergelijk bijvoorbeeld gedurende één PI de tijd voor refinement, wachttijd op besluiten, zichtbaarheid van afhankelijkheden en de mogelijkheid om werk zelfstandig te accepteren. Kies vooraf wanneer je de vereenvoudiging terugdraait.

Quality Engineering helpt hierbij door vanaf het initiatief naar bewijs te vragen: welke verwachting moet kloppen, welk risico verdient aandacht en welke feedback verandert onze beslissing? Voor gebruikersfunctionaliteit én technische verbeteringen blijven acceptatiecriteria, kwaliteitskenmerken en eigenaarschap nodig.

Een goed gekozen Epic maakt duidelijk waarom een verandering nodig is en hoe we leren of zij werkt. Gebruik vervolgens de niveaus die helpen om die verandering beheerst te leveren. Noem een lokale vereenvoudiging ook zo, zodat iedereen dezelfde betekenis gebruikt en de aansluiting op de rest van de organisatie behouden blijft.