Hoe je met agile requirements goede planningen maakt

Een opdrachtgever wil weten waar hij aan toe is. Dat is niet meer dan logisch. Hij wil weten wat hij krijg en wat het kost, voordat hij een IT project groen licht geeft. Dus hij vraagt om een planning met kostenraming.

Maar krijgt de opdrachtgever dan ook wat hij nodig heeft? 

Traditionele planning 

Voor het maken van een planning moet je in elk geval weten wat de scope en de requirements van het te ontwikkelen systeem zijn. En je moet weten hoeveel tijd het kost om die software te realiseren. Beide weet je aan het begin van het project nog niet.

Je moet dus een inschatting, een voorspelling doen. Maar hoe betrouwbaar en reëel is dat?

Requirements voorspellen

Voor het maken van de planning heb je de complete set requirement van het op te leveren eindresultaat nodig. Die requirements moeten juist en volledig zijn, zodat er tijdens het ontwikkeltraject geen grote wijzigen optreden. Want dan moet ook de planning en eventueel het budget aangepast worden. 

De afgelopen decennia hebben ons echter geleerd dat dat een onmogelijke opgave is. Uit onderzoek van Jones blijkt dat bij een project van 1,5 jaar het aantal requirements (tijdens de ontwikkeling van het systeem) gemiddeld met 43% toeneemt.

Dat komt niet alleen omdat het vrijwel onmogelijk is om op voorhand alle requirements op tafel te krijgen. Het komt ook omdat de inzichten en behoeften van de gebruikers en andere business stakeholders gedurende de rit wijzigen.

Benodigde ontwikkeltijd voorspellen

Je schat de benodigde ontwikkeltijd voor het implementeren van de requirements. Maar waar baseer je die inschatting op? Op een benchmark? Op ervaring? Hoe schat een ontwikkelaar of een projectmanager het aantal uren in?

Een steeds terugkerend probleem is dat die tijdsinschattingen achteraf niet erg betrouwbaar blijken te zijn. 

We zijn tijds- en budgetoverschrijdingen zelfs gewoon gaan vinden! Als je daar even over nadenkt zie je hoe absurd dat eigenlijk is. Opdrachtgevers baseren hun beslissingen op planningen waarvan eigenlijk iedereen weet dat ze verre van betrouwbaar zijn. En toch doen we het elk volgend project weer opnieuw.  

Maar gelukkig is er nu een alternatief.

Het agile alternatief

In een agile traject geven we de opdrachtgever geen schijnzekerheid, maar bieden hem voorspelbaarheid en transparantie.

Het gegeven dat de planning bij de start van een project onbetrouwbaar is, compenseren we door waardegedreven en incrementeel te werken. Daardoor kunnen we gegarandeerd binnen tijd en budget een systeem met veel businesswaarde opleveren. We kunnen alleen niet garanderen met welke functionaliteit exact. 

Dat mag de business zelf bepalen tijdens de rit. De product owner (als afgevaardigde van de opdrachtgever en de business) bepaalt welke functionaliteit (user stories) als eerste gebouwd wordt. De prioritering van de user stories in de product backlog stelt hij voornamelijk vast op basis van de verwachte businesswaarde.

Bovendien mag de product owner of opdrachtgever er gaandeweg de rit voor kiezen om de voorziene functionaliteit te beperken. Dat kan nodig zijn om binnen budget te blijven. Of hij mag er ook voor kiezen om meer (of minder ) sprints te doen. Dat kan nodig zijn om alle gewenste functionaliteit te realiseren.

Planningen op basis van de realiteit

Agile biedt de tools om inzichtelijk te maken wat er binnen tijd en budget opgeleverd kan worden. Na gemiddeld 3 sprints kunnen agile teams daar al een reëel beeld van geven. En dat wordt snel daarna echt betrouwbaar.

Dat komt omdat je je in agile baseert op de realiteit en niet op voorspellingen (zoals bij traditionele planningen). Je hoeft de requirements niet te voorspellen en dus niet op voorhand op te stellen. In plaats daarvan baseer je de planning op het aantal te realiseren punten (story points). Hoe dat in z’n werk gaat lees je in het blogartikel Zo geef je ‘zekerheid’ aan het management.

Ook de benodigde ontwikkeltijd hoef je niet te voorspellen. In plaats daarvan baseer je de planning op ervaringscijfers. Je neemt de gemiddelde ontwikkelsnelheid van het team in de laatste 3 sprints. Bij een ingewerkt team is dat een betrouwbare maatstaf. Alle sprints hebben immers dezelfde lengte en vergen dezelfde type werkzaamheden.

Betrouwbare planningen

Om weg te blijven van de schijnzekerheid van fixed price – fixed time – fixed scope planningen, heeft de opdrachtgever de keuze tussen:

A. Gegarandeerd binnen tijd en budget, en zelf elke sprint opnieuw de mogelijkheid om de scope te bepalen. Binnen de mogelijkheden uiteraard. En met in acht neming van de gemiddelde ontwikkelsnelheid van het team.   

Door het aantal resterende sprints te vermenigvuldigen met de velocity (gemiddelde ontwikkelsnelheid uitgedrukt in punten), krijg je het totaal aantal punten dat nog gerealiseerd kan worden. Welke requirements dat zijn is voor de planning niet van belang.

B. Gegarandeerde scope, en niet onaangenaam verrast worden door tijds- en budgetoverschrijdingen. Ook niet als gevolg van wijzigingen in de requirements of de scope.   

Door het totaal aantal nog te realiseren punten (story points) te delen door de gemiddelde ontwikkelsnelheid (velocity), krijg je het aantal benodigde sprints om de resterende functionaliteit (user stories) te realiseren. 

Discussie

Ik ben me ervan bewust dat dit onderwerp de nodigde reacties en discussies oproept. En inhoudelijke discussies juich ik altijd toe. Daar kun je veel van leren. Dus houd je niet in en plaats je reactie, kritische noot of ervaringen met planningen onder dit artikel.

Nicole de Swart, requirementstechnieken expert
Nicole de Swart

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