‘De ontwikkelaars willen exact gespecificeerd hebben wat ze moeten bouwen en testen. Ik heb het daardoor erg druk met het uitwerken van de requirements. Maar nog blijven de ontwikkelaars en testers in mijn team continu vragen naar meer informatie en meer details. Ik word er soms moedeloos van.’

Zo beschreef Sebastiaan zijn situatie toen hij deelnam aan ons praktijkprogramma Daadkracht met agile requirements.

Sebastiaan voelde zich onder druk gezet. Hij werd geleefd en kwam niet meer toe aan zijn andere werkzaamheden als business analist. Hoe gedetailleerd hij de requirements ook specificeerde, het was nooit genoeg.

Sebastiaan is zeker niet de enige waarvan wordt verwacht dat hij de requirements tot in detail beschrijft. Iets vergelijkbaars zien we ook bij veel andere analisten. Onterecht worden wij nog vaak 100% verantwoordelijk gehouden voor de requirements.

Met een beetje pech gaan andere teamleden dan achteroverleunen en kritiek leveren op de specificaties in plaats van samenwerken als één team

Omdat we dit nog steeds geregeld tegenkomen, delen we ons advies aan Sebastiaan in dit artikel.

Daag de ontwikkelaars uit

We hebben Sebastiaan verschillende ideeën en suggesties aan de hand gedaan om zijn probleem op te lossen. De volgende tip sprak hem het meeste aan.

Maak inzichtelijk hoeveel requirementsdocumenten er op dit moment al opgesteld zijn. Daag vervolgens de ontwikkelaars uit om samen met jou vast te stellen welke specificaties ze echt nodig hebben. Dat doe je bijvoorbeeld door ze de volgende twee opties te geven:

Optie 1 – We spreken af welke requirementsdocumentie en -specificaties er precies uitgewerkt moeten worden. Voordat jullie gaan bouwen moeten jullie die dan ook echt allemaal lezen.

Optie 2 – We gaan een andere werkwijze met minder specificaties uitproberen, waarbij:

  • We minimaal 1 keer per week een refinement doen. Dit is een interactieve sessie met het hele agile team en vertegenwoordigers van de business. We spreken daarin de user stories voor de aankomende 2 of 3 sprints door en zorgen samen dat de requirements helemaal duidelijk worden.
  • We de summiere beschrijving van een user story alleen aanvullen met extra specificaties als dat echt noodzakelijk is.
  • Ik de hele sprint stand by blijf om jullie vragen over de user stories van de lopende sprint te beantwoorden.

Onze ervaring is dat je ongeacht de keuze van de ontwikkelaars uiteindelijk op heel veel minder specificaties uitkomt.

Drie praktijkvoorbeelden

Dit zijn onze persoonlijke ervaringen met de tactiek. 

Papieren toren – Priya heeft een keer letterlijk alle requirementsdocumenten die al waren opgesteld op papier uitgeprint. De papieren toren die als gevolg van deze actie uit de printer rolde (gelukkig was het gerecycled papier) op een tafel gelegd en het team de 2 opties voorgelegd. Je raadt het al: het team koos voor optie 2.

Stapel halveren – In een ander project waren de teamleden uiterst kritisch en werd de stapel eerst gehalveerd, en nog een keer gehalveerd, en nog een keer … en uiteindelijk kwamen we uit op 10% die echt relevant was en waarde had voor de klus. Die 10% van de oorspronkelijke documentatie is later nog teruggebracht naar 5%. Daarmee bleek de essentie van de functionaliteit die gerealiseerd moest worden goed te duiden.

Top 3 – Met alle teamleden samen hebben we een keer een top 3 vastgesteld van de informatie die aanvullend op de user story beschrijving gespecificeerd moest worden. Dit hebben we een aantal sprints uitgeprobeerd. In het begin wisselde de top 3 per sprint, maar al snel kwamen we tot een gulden middenweg.

De grootste winst

Sebastiaan zag ons derde praktijkvoorbeeld helemaal zitten. Dat bracht hem tot de volgende uitspraak, waar wij hartelijk om moesten lachen.

Papieren tijger slachten

Het inzicht dat de ontwikkelaars met deze ervaring opdeden, was uiteindelijk de grootste winst. Ze kwamen erachter dat ze veel meer te weten komen door zelf de details te verkennen, dan wanneer ze alleen lezen wat een ander geschreven heeft.

De ontwikkelaars ontdekten ook dat ze vooraf niet alle informatie nodig hebben. De details volgen vanzelf door zich tijdens de sprint in de user story te verdiepen.

Wat is jouw ervaring met ontwikkelaars? Willen ze per se gedetailleerde specificaties of kunnen ze overweg met agile requirements? Deel je ervaring in het reactieveld hieronder. Wij (en de andere lezers) kijken ernaar uit.


Nicole de Swart & Priya Soekhai

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
Powered by Social Snap