Het is een van de belangrijkste punten waar analisten tegen aan lopen: user story details uitwerken. Hoever moet je daarin gaan?
Het advies dat in agile vaak gegeven wordt is just enough en ook nog eens just in time. Echt concreet is dat niet. Ik begrijp heel goed dat mensen worstelen met het uitwerken van user story details.
Wat het nog eens extra lastig maakt is dat de benodigde user story details situatieafhankelijk zijn. Hoe beter business en IT op elkaar ingespeeld zijn, hoe minder details voorafgaand aan de sprint uitgewerkt hoeven te worden (tenzij het management ze vereist). En ook kunnen er voor de ene user story meer details nodig zijn dan voor de andere user story.
Hoe bepaal je de benodigde user story details?
Het goede nieuws is dat de hoeveelheid user story details minder belangrijk zijn dan je nu waarschijnlijk denkt. In agile neem je namelijk de ruimte om de requirements en de ontwikkelde software voortdurend bij te stellen. Het is daarom niet de bedoeling om meteen de definitieve requirements en alle details vast te stellen.
Als je agile wilt werken is het belangrijk om je de volgende 4 punten te realiseren:
> Het is voor jou als analist niet te doen om te bepalen welke mate van detail voor een user story vereist is
Wat lang niet iedereen weet is dat de ontwikkelaars zelf de verantwoordelijkheid hebben om de benodigde requirements op tafel te krijgen. Zij weten het beste welke detailinformatie ze voor het realiseren van een user story nodig hebben.
Van de ontwikkelaars wordt dan ook verlangd dat ze actief betrokken zijn bij het achterhalen en scherpstellen van de user stories. Zij moeten meedenken en vragen blijven stellen totdat ze genoeg informatie hebben. Veel ontwikkelaars hebben daar de hulp van een analist bij nodig.
Helaas staan niet alle ontwikkelaars hiervoor open. Sommige ontwikkelaars blijven complete specificaties vragen en weigeren actieve betrokkenheid bij het uitwerken van user story details. Als jij ook met dit soort traditioneel denkende ontwikkelaars te maken hebt, zijn hier een aantal tips om hun betrokkenheid te vergroten.
> Requirements en user stories zijn slechts een momentopname
De praktijk heeft ons geleerd dat veel requirements later nog wijzigen, zelfs bij een watervalaanpak waar je wijzigingen probeert te beperken.
Dat komt omdat je niet weet, en nog niet kunt weten, welke systeemondersteuning de business exact nodig heeft. Ook de business stakeholders kunnen dat nog niet precies weten, hoewel ze er soms wel een duidelijke mening over hebben.
In hybride (deels agile deels waterval) organisaties kom je er gewoonlijk niet onderuit om op voorhand behoorlijk veel details in de requirements op te nemen. Mijn advies is dan: doe dat zo laat en zo weinig mogelijk (zoek de grenzen op) én beschouw die requirements in ieder geval zelf (en binnen de agile teams) als momentopnamen.
> Voortschrijdend inzicht is positief
Voortschrijdend inzicht betekent dat je nu iets weet dat je voorheen nog niet wist. Je bent wijzer geworden, je hebt iets geleerd. In het geval van requirements heeft de business beter zicht op haar werkelijke (automatiserings)behoeften gekregen. Dat is dus positief.
Agile analisten doen er alles aan om de business te helpen achter hun werkelijke behoeften te komen. Dat doen ze door de stakeholders al vroegtijdig de reeds gebouwde software te laten uitproberen. Ze ervaren dan wat wel en wat niet handig werkt en welke functionaliteit verder nog noodzakelijk is.
> De ‘demo’ aan het einde van de sprint zou een feedback meeting moeten zijn
In scrum vindt aan het einde van de sprint een ‘sprintreview’ plaats. In de praktijk wordt dit vaak demo genoemd. Deze naam dekt echter de lading niet. En erger nog: met de naam demo geef je een verkeerd signaal af.
Demonstreren van het resultaat van de sprint is weliswaar onderdeel van de sprintreview, maar is zeker niet het belangrijkste onderdeel. Het is bedoeld om de gerealiseerde software te laten reviewen door de business. Vandaar de veelzeggende naam sprintreview.
Als je er het label ‘demo’ op plakt, wordt het al snel een demonstratie om verantwoording over het werk in de sprint af te leggen. Daarmee mis je het belangrijkste moment dat in scrum is ingebouwd om feedback van de business te krijgen.
Conclusie
Als je bovenstaande punten goed voor ogen houdt, ga je je vanzelf meer richten op het gaandeweg steeds beter in beeld brengen van de werkelijke gebruikersbehoeften. De hoeveelheid user story details worden dan minder belangrijk.
Als jij samenwerkt met traditioneel denkende stakeholders komt er een complicerende factor bij. Ik help je graag om ook dan de requirements agile te blijven uitwerken. Het trainingsprogramma Daadkracht met agile requirements is daar speciaal voor bedoeld.
Je reactie, vraag of opmerking over dit artikel is zoals altijd meer dan welkom.
Nicole de Swart
Dag Nicole, op dit moment zijn we binnen onze organisatie aangekomen op het punt dat er regelmatig meningsverschil is over de mate waarin een opgestelde user story ‘ready for sprint’ dient te zijn. Mijn mening: De volledige uitwerking is inderdaad niet bij elke user story noodzakelijk of direct inzichtelijk, maar er zal voor de oplevering (sprintdoel) toch een werkend geheel moeten zijn. Ik merk wel dat het ophalen van requirements nog veelal de verantwoordelijkheid is van 1 persoon (buisiness/requirementsanalist) en de product-owner op de kwaliteit van geleverde user stories een behoorlijke druk legt. Het ophalen van de businessrequirements wordt nauwelijks als een teamverantwoordelijkheid gezien.
Daarnaast krijg je ook nog te maken met de remmende werking van de bestaande systeemlogica die de mogelijkheid om te voldoen aan de businessrequirements in de weg staat.
Heb je tips?
Hallo Johan, dank voor je reactie. Het gaat er niet om in welke mate een user story ‘ready for sprint’ dient te zijn, want dat moet iedere user story zijn vlak voordat hij in de sprint opgenomen wordt. De vraag daarbij is welke info dan bekend moet zijn en welk deel daarvan schriftelijk vastgelegd dient te worden. Hoe meer het achterhalen van de requirements (vooral het detailleren van de stories) een teamverantwoordelijkheid is, hoe minder noodzaak er is om alle info schriftelijk vast te leggen. Zie https://www.reaco.nl/blog/wat-als-de-ontwikkelaars-volledig-gespecificeerde-requirements-willen/ voor tips over het verhogen van de betrokkenheid van het hele agile team. Als de bestaande systeemlogica een issue is bij jullie, is dat des te meer reden om de ontwikkelaars een actieve rol te laten spelen (of daartoe te stimuleren) bij het uitwerken van de user stories.