In mijn vorige blog
heb ik het gehad over de werkzaamheden van de Agile Business Analist.
Eén van de grootste uitdagingen die de Agile Business Analist heeft, is
de vertaling van een business requirement naar een User Story waar het
scrum team daadwerkelijk mee aan de slag kan. Nadere specificatie is in
dit geval vereist. Behaviour Driven Development (BDD) speelt in op deze
eis. Hoe precies, dat licht ik toe in dit artikel.
Behaviour Driven Development maakt User Stories concreet
Behaviour Driven Development focust op specificatie met voorbeelden.
Deze voorbeelden komen tot stand aan de hand van drie perspectieven: het
business, ontwikkel- en testperspectief, verwezenlijkt door de ‘Three Amigo’s’ die in een gezamenlijke sessie de User Stories met bijhorende requirements en acceptatiecriteria bespreken. Om je een
beter beeld van deze opzet te geven, zie je hieronder een schematische
weergave ervan:
Drie Amigo’s op één lijn
Het doel van deze sessie is om ervoor te zorgen dat alle drie de
Amigo’s hetzelfde beeld hebben bij de User Story en het werk dat moet
worden verricht om tot het gewenste resultaat te komen. Dat beeld
ontstaat dankzij de drie genoemde perspectieven:
- Vanuit het businessperspectief kijken de Amigo’s naar de dekkingsgraad ten opzichte van de requirements.
- Het ontwikkelperspectief helpt ze te controleren of de vraag wel te vertalen is naar een stuk software.
- Met het testperspectief bedenken ze goed- en foutpaden om de acceptatiecriteria te controleren.
Het BDD-scenario
Volgens de Behaviour Driven Development methode is een voorbeeld
nodig om de User Story te kunnen bouwen (en testen). Dit is het
BDD-scenario:
Gegeven… [de situatie/ context waar de gebruiker of het systeem zich in bevindt]
Als ik… [de actie die ik uitvoer]
Dan verwacht ik… [het systeem vertoont gedrag X].
Van requirement naar BDD-scenario
Binnen BDD kennen we de volgende drie ‘producten’ om tot een stuk
software te komen. Punt 1 en 2 zijn input voor de Three Amigo sessie.
Punt 3 is output van de Three Amigo sessie en input voor het
ontwikkelwerk in een Sprint. Ze komen als volgt tot stand:
-
Business requirement --> User Story: de Product Owner stelt de business requirements op. Het team verzamelt deze requirements en stelt User Stories op.
-
User Story --> acceptatiecriteria: het team formuleert
acceptatiecriteria. De Product Owner controleert deze om er zeker van te
zijn dat alle requirements zijn gedekt.
- Acceptatiecriteria --> BDD-scenario: het team schrijft voor elk
acceptatiecriterium een of meer BDD-scenario’s. Dit is de input voor
development. Naast de business scenario’s bedenkt het team ook
specifieke ‘missing’ test scenario’s.
User Stories bouwen en testen
Het team bouwt de stories en (automatische) tests aan de hand van
opgestelde BDD-scenario’s. Onderstaand figuur geeft aan welke expertises
er nodig zijn om deze producten te realiseren:
Om de werking van het BBD-scenario te verduidelijken geeft ik twee voorbeelden:
Voorbeeld 1
Het business requirement dat met het eerste voorbeeld wordt gerealiseerd, is:
“Het systeem berekent en verstuurt facturen inzake membership fees automatisch, direct na registratie.”
Voorbeeld 2
In het tweede voorbeeld wordt het requirement “Afwijkingen van de
gestelde tijdsperiode voor audits zijn alleen mogelijk met een
onderbouwing. Medewerkers van member support controleren de geldigheid
van deze onderbouwing handmatig.” gerealiseerd.
Transparantie leidt tot business waarde en commitment
Scrum teams krijgen past echt commitment van de business wanneer het
voor hen inzichtelijk en begrijpelijk is waar ze mee bezig zijn. Door
User Stories uit te breiden met de situatie, de actie en het gewenste
gedrag, is voor iedereen helder wat (en hoe) er gebouwd wordt. Alleen
dan kan de business controleren en bevestigen dat er waarde wordt
geleverd. Door de verschillende BDD-producten 1:1 met elkaar te linken
en dit te bespreken in de Three Amigo sessie, waarborg je tevens een
volledig afgestemde dekkingsgraad van requirements.