Blog post
De strategische rol van de business analist in Agile.
Posted by
on
maart 12, 2026
Projectoverzicht
Van analyse naar PI-planning.
Mijn naam is Niels Hammink en ik ben Business Analist bij Gorilla IT. Een van mijn belangrijkste opdrachten was het ondersteunen van een project bij GS1, waar ik gestructureerde, modelgedreven analyse toepaste om stakeholders op één lijn te brengen, requirements te verduidelijken en strategische besluitvorming binnen de organisatie te stimuleren.
Voor wie het niet weet: GS1 is een organisatie die standaarden ontwikkelt en onderhoudt voor identificatie in supply chains. Als je een willekeurig retailproduct oppakt, bijvoorbeeld een doosje rozijnen, zie je een barcode op de verpakking. Die barcode is gebaseerd op een GS1-standaard. Zij zijn verantwoordelijk voor het uitgeven van deze identificatienummers en het onderhouden van de wereldwijde standaarden erachter.
Op dat moment werd Gorilla IT gevraagd om GS1 te helpen bij het realiseren van nieuwe functionaliteiten in hun klantenportaal, het systeem waarin klanten inloggen en hun producten en gerelateerde data beheren.
Gestructureerde focus
Een gestructureerde manier van werken binnenstappen.
Toen we bij GS1 begonnen, viel me al snel op dat mijn rol als Business Analyst anders was dan wat ik eerder had meegemaakt in Agile projecten. GS1 werkt in een Agile ontwikkelomgeving waarin werk wordt georganiseerd en afgestemd via kwartaalgerichte planningscycli.
Voor mij persoonlijk betekende dat dat ik verantwoordelijk was voor het voorbereiden en analyseren van een volledig kwartaal aan werk, vooraf. Die verantwoordelijkheid voelde tegelijk spannend en behoorlijk intens. Als de analyse niet goed was voorbereid, begon het hele kwartaal met onzekerheid. Tijdens het PI-event zijn er veel stakeholders aanwezig. Als de voorbereiding onduidelijk of incompleet is, wordt dat meteen zichtbaar. Dat maakte de verantwoordelijkheid heel tastbaar.
Tegelijkertijd ontdekte ik dat deze gestructureerde manier van werken juist goed bij me paste. Het hebben van een duidelijk PI-event als vast ijkpunt hielp enorm. Ik wist altijd waar ik naartoe werkte. Er was een helder einddoel. In plaats van alleen te focussen op kleine sprintfunctionaliteiten, kon ik het grotere geheel zien. Het volledige initiatief. Het bredere verhaal.
Naar mijn mening werkt dat veel beter. Je bouwt niet zomaar losse stukjes. Je werkt aan iets substantieels. Het voelt doelgericht en betekenisvol. De structuur gaf me focus. Het voorkwam dat analyse alle kanten op ging. Het hielp me om bewust te werken richting iets dat er echt toe doet.
Kwartaalrichting
De Business Analist bereidt het kwartaal voorafgaand aan het PI-event voor, waarbij prioriteiten, afhankelijkheden en onzekerheden in kaart worden gebracht zodat teams met een helder perspectief kunnen plannen.
Modelgedreven helderheid
Modellen maken relaties, grenzen en impact zichtbaar. Dat vermindert interpretatieverschillen en zorgt voor een gedeeld begrip voordat er beslissingen worden genomen.
Alignment in één ruimte
PI-events brengen stakeholders samen rondom dezelfde context, op hetzelfde moment. Daardoor worden afwegingen expliciet en wordt planning realistischer.
Realiteit boven enthousiasme
Analyse maakt capaciteit, scope en afhankelijkheden concreet, zodat beslissingen gebaseerd zijn op wat binnen het kwartaal past, niet alleen op wat goed klinkt.
Ontdek onze diensten.
Artificial Intelligence.
Met onze AI-oplossingen richten we ons op meetbare impact. We bouwen systemen die werk automatiseren, besluitvorming ondersteunen en naadloos integreren met bestaande processen.
Business Analyse.
Door aannames bloot te leggen, prioriteiten te verduidelijken en stakeholders op één lijn te brengen, zorgen onze business analisten ervoor dat de juiste problemen worden opgelost en beslissingen bewust worden genomen.
Maatwerk Software.
Wij ontwerpen en bouwen maatwerksoftware die aansluit op de processen, data en doelstellingen van jouw organisatie. Met een gestructureerde aanpak leveren we snel schaalbare oplossingen.
Visuele helderheid
Het toepassen van de All Systems Go-methode.
Bij Gorilla IT gebruiken we de All Systems Go-methode. We adviseerden GS1 om dezezelfde modelgedreven aanpak binnen hun organisatie toe te passen, wat betekende dat ik het goede voorbeeld moest geven. Ik was verantwoordelijk voor het toepassen van de methode, het laten zien hoe je ermee werkt en het consistent inzetten ervan in mijn analysewerk. Een belangrijk onderdeel van deze methode is modelgedreven analyse, en dat heeft mij persoonlijk veel geholpen.
Wanneer ik een onderwerp ontving van een stakeholder, begon ik met een as-is analyse:
-
Wat is de huidige situatie?
-
Waar zitten de knelpunten?
-
Welke requirements bestaan er al?
-
Welke beperkingen zijn van toepassing?
Pas wanneer de huidige situatie volledig begrepen en gevalideerd was, ging ik over naar het definiëren van de to-be situatie.
Wat ik vooral waardeerde aan de modelgedreven aanpak, is dat het me hielp op het juiste abstractieniveau te blijven. Het voorkwam dat ik te vroeg in details dook. Door visueel en gestructureerd te werken, kon ik het overzicht bewaren. Eerst het totaalplaatje zien, daarna pas inzoomen.
Ik merkte ook dat ik complexiteit sneller begrijp wanneer die visueel wordt gemaakt in plaats van beschreven in lange teksten. Dat helpt om de juiste vragen te stellen over scope en impact, en stelt stakeholders in staat om beter onderbouwde beslissingen te nemen.
Op het niveau van kwartaalvoorbereiding was deze high-level analyse essentieel. Het doel was nog niet om alles tot in detail uit te werken, maar om duidelijkheid te creëren over scope en impact. Wat proberen we te bereiken in de to-be situatie? Hoe groot is dit initiatief? Welke systemen en stakeholders worden geraakt? Deze gestructureerde, high-level analyse zorgde voor overzicht en vertrouwen.
Gedetailleerde voorbereiding
Van high-level overzicht naar use cases.
Zodra de to-be situatie op hoofdlijnen was gedefinieerd, ging ik over naar meer gedetailleerde analyse en werkte ik use cases verder uit. Voor PI-events bereidde ik enterprise-architectuurmodellen en high-level procesoverzichten voor, vaak in BPMN-stijl:
-
De end-to-end procesflow
-
Systeeminteracties
-
Stakeholder touchpoints
-
Functionele afbakeningen
Tijdens het PI-event presenteerde ik deze overzichten om alle stakeholders op één lijn te brengen: “Dit is het proces. Zo ondersteunt het systeem dit. Op hoofdlijnen is dit hoe de functionaliteit eruit gaat zien.” Omdat ik hier weken aan had gewerkt, merkte ik dat ik het initiatief moeiteloos kon uitleggen, zonder zware voorbereiding. Dat gaf vertrouwen.
Na de plenaire sessie werkten developmentteams het initiatief verder uit in break-outsessies. Doordat de alignment al stond, konden we direct de diepte in: use cases uitwerken, user stories afleiden en de scope scherp definiëren.
Mijn doel was om ongeveer 80–90% van de analyse afgerond te hebben vóór het PI-event. Er blijven altijd kleine verfijningen nodig, dat is normaal. Maar de basis moest stevig zijn. En als die stevig is, merk je dat meteen. In plaats van stress tijdens het PI-event voelde ik me voorbereid. De verantwoordelijkheid bleef, maar veranderde van druk naar vertrouwen.
Richting geven
Wat dit mij heeft geleerd.
Deze manier van werken heeft mijn kijk op business analyse veranderd. Het gestructureerde ritme van PI-events werkt voor mij erg goed. Ik werk graag toe naar iets concreets en betekenisvols. Het geeft richting en doel. Het voorbereiden van een volledig kwartaal kan in het begin overweldigend voelen, maar het zorgt voor eigenaarschap en helderheid. De verantwoordelijkheid kan zwaar aanvoelen, zeker omdat veel stakeholders tijdens het PI-event afhankelijk zijn van jouw analyse. Maar wanneer de voorbereiding grondig is, verandert diezelfde verantwoordelijkheid in kracht.
Modelgedreven denken hielp me om gestructureerd te blijven, het grotere geheel te zien en complexiteit sneller te begrijpen. Het voorkwam dat ik verdwaalde in details en stelde me in staat om bewust van de as-is naar de to-be situatie te bewegen. Daarnaast realiseerde ik me dat business analyse in deze context meer is dan het vastleggen van requirements. Het gaat om het creëren van helderheid vóórdat de uitvoering begint en het vormgeven van initiatieven op het juiste niveau, zodat teams met vertrouwen kunnen bouwen.
Toen ik het project afrondde, werd duidelijk dat juist de combinatie van structuur, eigenaarschap en modelgedreven denken het verschil maakte. Het verschil tussen meedraaien in Agile en daadwerkelijk richting geven.
Over Niels Hammink.
Niels is een van de business analisten bij Gorilla IT en blinkt uit in structuur, consistentie en besluitvorming. Hij maakt afwegingen expliciet, houdt requirements concreet en zorgt ervoor dat kwaliteit vanaf het begin wordt ingebouwd in plaats van later ontdekt. Naarmate systemen zich ontwikkelen, zorgt zijn werk ervoor dat ze begrijpelijk, beheersbaar en in lijn met de bedrijfsdoelstellingen blijven.
Door ambiguïteit om te zetten in helderheid, keuzes in structuur en ideeën in concrete resultaten, kunnen teams daadwerkelijk leveren.
Business analyse die echte alignment creëert en betere beslissingen mogelijk maakt.
