Agile requirements vallen of staan met de actieve betrokkenheid van de business en het scrum team. De samenwerking moet van twee kanten komen. De vertegenwoordigers van de business én het scrum team moeten bereid zijn om actief te participeren bij het uitwerken van requirements.

Het kan een hele klus zijn om dat voor elkaar te krijgen. Zeker wanneer er over en weer weinig vertrouwen is. Als analist kun je daar een belangrijke rol in spelen.

Ervaring met vergroten betrokkenheid business en scrum team

Betrokkenheid kun je niet afdwingen. Maar je kunt wel een heleboel doen om betrokkenheid te stimuleren. En zo betrokkenheid geleidelijk opbouwen en vergroten. En bedenk dat elk stapje in de goede richting winst is.

Onze ervaring is dat vergroten van actieve betrokkenheid tijdens de refinement of tijdens de sprintreview grote impact heeft op het succes van het ontwikkeltraject. Van beide geven we een voorbeeld van hoe je dat zou kunnen bevorderen. 

Actieve betrokkenheid scrum team tijdens refinement

Bij een product backlog refinement verfijnen de product owner (doorgaans bijgestaan door een analist en/of gebruikersvertegenwoordigers) en het ontwikkelteam de user stories op de product backlog.

Als het goed is bespreken ze samen, als volwaardige sparringpartners, hoe het systeem de gebruikers het beste kan ondersteunen. In de praktijk zien we vaak dat één van beide partijen onvoldoende betrokken is. Als bijvoorbeeld scrum teamleden wel aanwezig zijn maar niet actief meedoen, is het tijd om in actie te komen. 

Meer verantwoordelijkheid geven

Een manier om de betrokkenheid van de ontwikkelaars te vergroten is door ze meer verantwoordelijkheid te geven. Dat klinkt wellicht tegenstrijdig. Maar doordat je hiermee een beroep doet op hun expertise en creativiteit pakt het vaak positief uit.

Een beproefde manier om dat te doen is door ontwikkelaars een actieve rol te geven bij het definiëren van user stories. Je maakt dan bijvoorbeeld afspraken over het invullen van het user story template: Als <gebruiker> wil ik <functionaliteit>, zodat <businesswaarde>.

Je spreekt af dat de business stakeholders uitsluitend de onderdelen ‘gebruiker’ en ‘businesswaarde’ mogen invullen. Het ontwikkelteam krijgt de verantwoordelijkheid de ‘functionaliteit’ die nodig is om de businesswaarde te leveren, te definieren.

Dit dwingt ze om zich in de business en de gebruikers te verdiepen. Als analist kun je ze eventueel op weg helpen met het stellen van handige vragen.

Bijkomend voordeel is dat de product owner en de business stakeholders gestimuleerd worden de businesswaarde goed te verwoorden.

Actieve betrokkenheid business tijdens sprintreview

Met de iteratieve werkwijze van agile wil je minimaal eens per sprint feedback van business stakeholders. Feedback op de gerealiseerde software wel te verstaan. Dan pas gaat het systeem voor de business leven. En worden hun behoeften (d.w.z. requirements) helder. Scrum heeft hier de sprintreview meeting voor in het leven geroepen.

In de praktijk zien we vaak dat de sprintreview niet meer is dan een demonstratie van de ontwikkelde software. En meestal ook een manier van het ontwikkelteam om verantwoording af te leggen. Dat verklaart waarom de sprintreview gewoonlijk (onterecht) demo wordt genoemd.

Het is dan ook niet verwonderlijk dat business stakeholders niet gemotiveerd zijn om naar de sprintreview te komen. Het goede nieuws is dat het de andere kan op net zo werkt. Maak de sprintreview interessant voor de business stakeholders en ze komen er graag naar toe.

Feedbackvragen stellen

Tijdens de sprintreview wil je actieve betrokkenheid van de business. Je wilt het liefst een volwaardige dialoog tussen business en scrum team. Een manier om de betrokkenheid van de business stakeholders te vergroten is het stellen van feedbackvragen.

Dat gaat sowieso een hoop nuttige informatie over de requirements opleveren. En als het ontwikkelteam nog geen rechtstreeks contact met de business heeft, is dit de eenvoudigste manier om ze te laten ervaren hoe nuttig dat is.

Het valt of staat echter met de kwaliteit van de feedback opmerkingen die je van de business krijgt. Voorkom daarom dat de feedback alleen over schermdetails en punten en komma’s gaat.  Dat doe je door steeds terug te grijpen op het grotere geheel, de productvisie en het bedrijfsdoel. Alleen dan zie je welke user stories en requirements de meeste businesswaarde leveren.

Bespreek tijdens de sprintreview met alle aanwezigen waar de focus van de volgende sprint op moet liggen. Deze reviews moeten de plek worden waar business en scrum team bepalen hoe het systeem sprint na sprint vorm krijgt. Naar de sprintreviews komen, wordt dan dé manier om invloed op het in ontwikkeling zijnde systeem uit te oefenen.

Betrokkenheid vergroten?

We hopen dat dit artikel je genoeg ideeën en inspiratie heeft gegeven om de actieve betrokkenheid van de business en het scrum team te vergroten. Of in elk geval de eerste stap in de goede richting te zetten. Elk stapje in de goede richting is er één.

Hoe is in jouw situatie de betrokkenheid van business en scrum team bij de requirements? Ben je tevreden over de samenwerking? Vertel het ons in het reactieveld hieronder. We geven je graag nog aanvullende tips.

Je hebt meer invloed op je omgeving dan je denkt. Dat laten we je graag ervaren in onze masterclass Cocktail van agile en traditionele requirements.


Nicole de Swart & Priya Soekhai

Nicole de Swart

Nicole de Swart

Auteur Handboek Requirements

Volg Nicole op:

Priya Soekhai

Priya Soekhai

Expert agile samenwerken

Volg Priya op:

Tips over agile requirements

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.000 collega abonnees.

Abonneren op de tips

Je kunt je op elk moment weer uitschrijven

Copy link