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.
De vraag of er veel of weinig gedocumenteerd wordt of moet worden heeft m.i. niets te maken met de vraag of volgens ‘waterval’ of ‘Agile’ wordt gewerkt. Om te beginnen moeten we maar niet een al te grote voorstelling maken van de kwantiteit (en trouwens ook de kwaliteit) van de documentatie gemaakt tijdens watervalprojecten van enige tientallen jaren geleden. Met name de kwantiteit wordt vanwege het feit dat men Agile wil promoten (waar ik op zichzelf niets tegen heb) nogal al eens overdreven afgezien van het feit dat met de basisgedachte van waterval (‘eerst denken, dan doen’) niets mis is. Evenwel: documentatie werd en wordt beschouwd als corveewerk, dat was toen (30 jaar geleden) zo en nu nog. Als een watervalproject tegen de deadline onder druk kwam te staan was de documentatie het eerste dat sneuvelde (‘doen we later wel’, lees: ‘nooit meer’). De veelal beroerde staat van de systeemdocumentatie van oude maar nog draaiende legacy-systemen spreekt wat dat betreft boekdelen. Maar het verschil tussen toen en nu is dat Agile soms?/vaak? wordt gebruikt als een reden/smoes om helemaal niet te documenteren. Ik heb vaak gezeten in een rol waarbij ik als externe medewerker bestaande informatiesystemen moest begrijpen en doorgronden en u begrijpt hoe blij ik dan was als mij werd gezegd: ‘Documentatie? Die hebben wij niet want we werken Agile.’ Heel fijn. Zelfs als je vraagt om een datamodel wordt je soms glazig aangekeken.
Hetzelfde geldt voor de vraag: ‘hoe gedetailleerd moeten requirements zijn?’. Ook daar heeft het antwoord niets te maken met de gekozen werkwijze (Agile vs. waterval) maar met de aard van het door de applicatie bestreken materiegebied. Ik was vorige week nog bij een bedrijf dat roestvrij metaalschroot verhandelt. Daar gaat het om percentages nikkel, chroom, ijzer enz. en de prijzen die daarvoor worden gesteld. De berekeningen van de prijzen die het bedrijf moet betalen dan wel ontvangt (mede aan de hand van de dagprijzen op de internationale goederenbeurzen) zijn ingewikkeld, heel ingewikkeld. En het zijn die details die bepalend zijn voor de continuïteit van het bedrijf en die de ‘business’ ook als eerste geborgd wil hebben. En wat te denken van pensioensystemen, salarissystemen, GIS-systemen etc. Ik vind het veel te gemakkelijk om te zeggen dat de ontwikkelaar weet tot welk detail de specificatie moet gaan. Het gaat hier niet om IT-details maar om business-details en daar staan business- en informatieanalisten als eerste voor opgesteld. Helaas kom ik nog wel eens BA’en en IA’en tegen die roepen dat ze ‘niet van de details zijn’, zich alleen bezig willen houden met ‘de grote lijnen’ en zich snel uit de voeten maken als het ingewikkeld wordt. Dan mogen de ontwikkelaars het verder opknappen. Als ik IA- of FO-cursus geef peper ik de cursisten stevig in dat (business-)details belangrijk zijn. En nogmaals: dat staat er los van of je nu Agile/Scrum of op z’n ‘watervals’ werkt.
Kortom: veel of weinig documentatie? of gedetailleerd of niet gedetailleerd? zijn in het kader van de te kiezen werkwijze naar mijn mening de verkeerde vragen. Ik heb er een beetje moeite mee als in het kader van een Agile-werkwijze min of meer gesuggereerd wordt dat documentatie en details er niet toe doen.
Dank voor je zeer uitgebreide reactie.
Het is belangrijk onderscheid te maken tussen systeem- en projectdocumentatie. Zoals jij in je eerste alinea aangeeft, maak je systeemdocumentatie voor beheer en onderhoud. Dat kun je het beste tijdens de sprint doen, direct nadat de software is gebouwd. Ingewikkelde bedrijfsregels zou ik daar zeker in opnemen. Het artikel gaat echter niet over systeemdocumentatie. Het gaat over het detailniveau van user stories en die zijn nodig om de juiste software te bouwen (d.i. projectdocumentatie). Het benodigde detailniveau hangt af van de werkwijze (zie https://www.reaco.nl/blog/hoeveel-requirements-moet-ik-specificeren/) en het materiegebied speelt inderdaad ook een rol.
Qua werkwijze maakt het nogal wat uit of je in opeenvolgende fases of iteratief en proefondervindelijk werkt. De voornaamste gevolgen van agile werken heb ik in dit artikel beschreven.
Ik ben het met je eens dat details er toe doen. Het punt is of je alles gedetailleerd wilt vastleggen voordat de software gebouwd wordt of dat je ze gaandeweg in een iteratief proces m.b.v. korte feedbackloops ontdekt/fijnslijpt.