Geef ontwikkelaars die gedetailleerde specs willen deze 2 opties‘Het ontwikkelteam wil precies gespecificeerd hebben wat ze moeten bouwen en testen. Ik heb het daardoor als product owner / analist erg druk met de requirements en het uitwerken van de specificaties. De ontwikkelaars en testers in mijn team blijven continu vragen naar meer op voorhand uitgewerkte details.’

Dit gaf Sebastiaan aan tijdens de online coaching van het webcollege ‘Benodigde detailniveau voordat de sprints starten’. Hij neemt deel aan ons trainings- en coachingsprogramma Agile requirements tot op het gewenste detailniveau uitwerken.

Hoe gedetailleerd Sebastiaan de requirements ook uitwerkte, het was nooit goed genoeg. De ontwikkelaars bleven naar meer specificaties vragen. Hij had het gevoel dat hij geleefd werd en kwam bijna niet meer toe aan zijn andere werkzaamheden.

Gouden tip

Omdat we veel vaker van dit soort geluiden horen, delen we ons advies aan Sebastiaan graag via dit artikel. Misschien is dit voor jou ook de gouden tip:

Daag het ontwikkelteam uit om samen met jou vast te stellen welke specificaties ze echt nodig hebben.

Dit doe je door inzichtelijk te maken hoeveel requirementsdocumenten er op dit moment al opgesteld zijn en het ontwikkelteam uit twee opties te laten kiezen:

Optie 1 – We spreken af welke requirementsdocumenten en specificaties er precies uitgewerkt moeten worden en jullie dus ook allemaal moeten lezen voordat jullie het gaan bouwen.

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

  • we minimaal 1 keer per week een requirements verfijningsmeeting (refinement) houden. Dit is een interactieve meeting waarin we met het hele ontwikkelteam en vertegenwoordigers van de business de user stories voor de aankomende 2 of 3 sprints gezamenlijk bespreken en uitwerken.
  • 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 voor vragen over de requirements van de lopende sprint.

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

Drie praktijkvoorbeelden

Papieren toren – Priya heeft in een project een keer letterlijk alle requirementsdocumenten die er al waren gemaakt (zonder dat er nog enig resultaat voor de business was gerealiseerd) op papier uitgeprint. De papieren toren die als gevolg van deze actie uit de printer rolde (gelukkig was het gerecycled papier) op een tafel gezet 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 documentatie is later nog teruggebracht naar 5%. Daarmee was de essentie van de functionaliteit die gerealiseerd moest worden goed te duiden.

Top 3 – Samen met een ontwikkelteam hebben we een keer een top 3 vastgesteld van specificaties die aanvullend op de user stories opgesteld moesten worden. Dat hebben we een paar sprints uitgeprobeerd. De top 3 wisselde per sprint en uiteindelijk kwamen we tot een gulden middenweg. De grootste winst was dat de ontwikkelaars ervaarden dat ze veel meer kennis en inzichten opdoen door zelf de details te verkennen, dan wanneer ze alleen lezen wat een ander heeft geschreven. Ze ontdekten dat ze vooraf alleen de hoofdlijnen nodig hebben en de rest vanzelf volgt als ze zich tijdens de sprint in de user story verdiepen.

Overtuigen

Je kunt proberen traditioneel denkende teamleden ervan te overtuigen dat het onmogelijk is om alles van tevoren te overzien. En dat het zinloos is om alle requirements gedetailleerd vast te leggen, omdat ze toch nog gaan wijzigen. Maar daar kom je meestal niet zover mee.

Ze laten ervaren dat de details zichzelf in het moment uitwijzen, en dat je ze dan pas hoeft te tackelen, zet veel meer zoden aan de dijk.

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 en Priya Soekhai

 

 

Vond je dit artikel interessant? Deel het dan met je vakgenoten via de share knoppen aan de zijkant.

Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Share This