Geef ontwikkelaars die gedetailleerde specs willen deze 2 optiesDit was de praktijksituatie waar Sebastiaan in zat: 

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.’

Sebastiaan schreef dit 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.

Ons advies aan Sebastiaan

Omdat we iets vergelijkbaars van veel meer analisten horen, delen we ons advies aan Sebastiaan in 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 requirementsproducten er op dit moment al opgesteld zijn. En het ontwikkelteam vervolgens uit de volgende twee opties laten kiezen:

Optie 1 – We spreken af welke requirementsdocumenten en specificaties er precies uitgewerkt moeten worden. Die moeten jullie dan ook allemaal lezen, voordat jullie 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 met het hele ontwikkelteam en vertegenwoordigers van de business. We bespreken daarin de user stories voor de aankomende 2 of 3 sprints en werken ze gezamenlijk uit.
  • 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 al waren opgesteld (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 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 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 story beschrijving 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 het inzicht dat de ontwikkelaars met deze ervaring opdeden. Ze kwamen erachter dat ze veel te weten komen door zelf de details te verkennen, dan wanneer ze alleen lezen wat een ander heeft geschreven. De ontwikkelaars ontdekten ook dat ze vooraf alleen de hoofdlijnen nodig hebben. De rest volgt vanzelf door zich tijdens de sprint in de user story te 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 gewoonlijk niet zo ver mee.

Ze laten ervaren dat de details zichzelf in het moment uitwijzen, en dat je ze dan pas hoeft te tackelen, is veel krachtiger en veel effectiever.

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.


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.

Copy link
Powered by Social Snap