Hallo analist,

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, requirementstechnieken expert
Nicole de Swart

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