De actieve betrokkenheid van business en scrum team vergroten

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 sprint review 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 templateAls <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 sprint review

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 sprint review meeting voor in het leven geroepen.

In de praktijk zien we vaak dat de sprint review 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 sprint review gewoonlijk (onterecht) demo wordt genoemd.

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

Feedbackvragen stellen

Tijdens de sprint review 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 sprint review 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 sprint reviews 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.


Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

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

Lees ook het recent door Priya geschreven blogartikel Samenwerken binnen scrum: 5 cruciale aspecten.
Copy link
Powered by Social Snap