Overzicht creëren is één van de dingen waar wij als analisten goed in zijn. We willen geen lange lijst met onsamenhangende requirements, want dan zie je door de bomen het bos niet meer.
Analisten brengen de samenhang in beeld en creëren een helikopter view. We werken top down: Van de doelen en probleem van de business naar uiteindelijk de te realiseren user stories en gedetailleerde requirements.
Hier hebben we allerlei requirementstechnieken voor, waarvan impact mapping en story mapping mijn persoonlijke favorieten zijn.
Epics, features en user stories
Een andere manier om overzicht te creëren en om te voorkomen dat je een ondoorzichtige lijst met requirements krijgt, is onderscheid maken tussen verschillende typen requirements. Bijvoorbeeld de indeling in epics, features en user stories kom ik dikwijls tegen.
Wat een handige indeling is is situatieafhankelijk. Hierbij is vooral de werkwijze en de mate waarin die werkwijze agile, waterval of een mix van beide is, van belang.
Voorbeelden
SAFe bijvoorbeeld heeft 4 typen requirements gedefinieerd, namelijk epics, capabilities, features en user stories.
Scrum daarentegen onderscheidt uitsluitend product backlog items, die steeds kleiner worden naarmate ze hoger op de product backlog staan.
Binnen de user story-techniek kent men aan hele grote user stories het label ‘epic’ toe. Dat blijven gewoon user stories, maar soms kan het handig zijn om ze epic te noemen. Daarmee benadruk je dat een bepaalde user story nog veel te groot en globaal is om in een sprint op te nemen.
Net zoals requirements globaal of gedetailleerd kunnen zijn, kunnen user stories groot of klein zijn. Ze hebben dus geen vastgestelde omvang.
Het heeft weinig zin om je af te vragen of iets een epic, feature, capability of whatever is. Dat gaat je niet helpen bij het vinden van de juiste requirements. Of het moet zijn dat je organisatie belangrijke consequenties aan die labels verbindt.
In ons gloednieuwe e-book ‘52 Agile requirements Tips & inspirerende Quotes’ hebben we daar onderstaande tip over opgenomen. Klik hier om het hele e-book gratis te downloaden.
Schijnzekerheid
Agile heeft me geleerd dat je niet mag doorslaan bij het creëren van overzicht. En dat een typering van requirements al snel schijnzekerheid geeft.
Ja, alles in een hokje plaatsen geeft overzicht en duidelijkheid, maar in een complexe omgeving is het eenvoudigweg niet mogelijk om alles te voorzien en te overzien. Dat moeten we ook niet willen en niet proberen!
Zeker voor analisten voelt dat onnatuurlijk. Ook voor mij.
Ik heb graag overzicht. Ik word zelfs onrustig als ik het overzicht verlies. Dan heb ik het gevoel dat ik de controle verlies. En bij mij veroorzaakt dat stress. Ik kijk bijvoorbeeld altijd vooruit en maak van van alles een todo-lijstje.
Complexe omgeving
Maar we moeten ook accepteren dat we de oplossing en de requirements niet volledig kunnen analyseren en volledig specificeren al helemaal niet. Hoe dynamischer en complexer de omgeving hoe meer onzekerheden en hoe meer voortschrijdend inzicht er zal optreden.
Tegenwoordig is dat eerder de regel dan de uitzondering.
Het is dan ook belangrijk om onze werkwijze daarop aan te passen. Dat wil zeggen veel minder vooraf analyseren en veel meer gaandeweg de rit ontdekken wat de requirements zijn. De iteratieve en incrementele aanpak van agile helpt je om proefondervindelijk achter de echte requirements te komen.
Ik ben benieuwd hoe jij overzicht creëert en hoe ver je daarin gaat. Zet je het even in het reactieveld hieronder? Alvast bedankt.
Nicole de Swart
Ik maak zelf onderscheid tussen “relatieve” en “absolute” requirements. De “relatieve” requirements brengen productversie “N” naar “N+1” per ontwikkeliteratie en zijn typisch backlog-items. De “Absolute” requirements beschrijven hoe productversie “N” hoort te werken en zijn typisch productdocumentatie en verificatietests.
Stel nu dat je een product “ownt” dat jarenlang in gebruik EN ontwikkeling is voor 3 of meer gebruikersgroepen. Bij elke user story uit doelgroep X ga je na of dat de “absolute” requirements verandert voor doelgroepen Y en Z en of dat acceptabel is. Doe je dat niet, dan heb je na de release je mailbox vol met correctie-stories (of ruzie) of switcht de implementatie van een methode telkesn van methode A naar B en weer terug.
Ik heb de indruk dat het op een agile- en lean-wijze beheersen van “absolute requirements” onderbelicht is. Of heb ik de juiste bronnen van informatie simpelweg niet gevonden?
Gerco, begrijp ik goed dat je met ‘relatieve’ requirements de gewenste wijziging bedoeld en met ‘absolute’ requirements de werking van een bepaald increment? Dus wat er aan het huidige increment toegevoegd of veranderd moet worden versus de toestand van het laatste increment?
Dat zou betekenen dat het voortbrengingsproces (de software ontwikkeling) plaatsvindt op basis van ‘relatieve’ requirements. En dat is precies waarop agile is gericht. Dat we diezelfde requirements vroeger voor meerdere doeleinden gebruikt (zoals documentatie, programma van eisen (voor offertes), beheer en onderhoud) leek verstandig maar was niet effectief.
Ik zou ‘absolute’ requirements geen requirements noemen. Ze beschrijven immers de functionele en/of technische werking van een product (niet de gewenste werking).
Dat je bij een user story voor doelgroep X rekening moet houden met andere doelgroepen (mag/moet het voor een andere doelgroep ook wijzigen of juist niet) onderschrijf ik volledig.
Overzicht is iets anders dan volledigheid.
Overzicht is dat wat je al wél weet in de juiste context bij elkaar brengen.
Overzicht vind ik cruciaal.
Volledigheid is inderdaad een illusie.