AgendaOpdrachtgevers willen gewoonlijk een betrouwbare planning voordat ze budget vrijgeven. Maar is dat wel reëel?

Het maken van een planning voordat de uitvoering van het project start klinkt logisch, maar is alleen goed mogelijk als het te voorspellen is. Je moet daarvoor de volgende voorspellingen doen:

  • Requirements voorspellen
    Je moet het gewenste eindresultaat en daarmee de requirements juist en volledig vaststellen, zodat ze tijdens het project niet meer wijzigen. De afgelopen decennia hebben ons 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 omdat de requirements niet volledig waren en inzichten en behoeften van de business wijzigen.
  • Benodigde ontwikkeltijd voorspellen
    Je moet de tijd die nodig is voor het implementeren van de requirements vaststellen. Maar waar baseer je dat op? Op benchmark of op ervaringen bij andere projecten? Erg betrouwbaar blijken die tijdsinschattingen niet te zijn. De meeste mensen schatten namelijk structureel te optimistisch.
Drijfzand

De afgelopen decennia hebben we onze ICT-projecten volgens een planmatige aanpak uitgevoerd. Tijds- en budgetoverschrijdingen zijn we gewoon gaan vinden. We kunnen het projectverloop nu eenmaal niet goed voorspellen en baseren de planning daarmee op drijfzand.

Het agile-alternatief

In een agile project geven we de opdrachtgever geen schijnzekerheid, maar bieden hem een eerlijk alternatief. Het gegeven dat de planning bij de start van een project onbetrouwbaar is, maken we acceptabel door waardegedreven te werken. We kunnen garanderen dat we binnen de afgesproken tijd en budget een waardevol systeem opleveren dat gebruiksklaar is. De opdrachtgever (of zijn afgevaardigde) krijgt de mogelijkheid om tussentijds bij te sturen en te ontdekken welke functionaliteit echt nodig is. Al na enkele sprints hebben agile projecten een reële planning.

In agile maak je bij de start van het project alleen een globale tijds- en kosteninschatting. Meer tijd en energie steken in een uitgebreide planning zorgt niet voor een hogere betrouwbaarheid. Tijdens het project daarentegen heb je snel (na 2 of 3 sprints) een reële planning die heel snel echt betrouwbaar is. Dat komt omdat je de planning niet baseert op voorspellingen maar op de realiteit:

Waarzegster
  • Requirements NIET voorspellen
    Om te voorkomen dat de onvermijdelijke wijzigingen in requirements de planning onbetrouwbaar maken, baseer je de planning op het aantal te realiseren punten (story points) in plaats van de requirements zelf. Het nauwkeurig vaststellen van de requirements hoeft dan niet.
    Van iedere (globale) requirement schat het ontwikkelteam het aantal punten is. Die punten geven aan hoeveel inspanning het kost om hem te implementeren. De punten zijn relatief. Ze geven aan dat requirement X bijvoorbeeld 5 keer zoveel ontwikkeltijd kost dan requirement Y. Dit soort relatieve schattingen zijn een stuk betrouwbaarder gebleken dan absolute schattingen (in uren).
  • Benodigde ontwikkeltijd NIET voorspellen
    De benodigde ontwikkeltijd baseer je op ervaringscijfers, op de daadwerkelijk bestede tijd door dit ontwikkelteam in dit project. Doordat je werkt in sprints met een vaste lengte en je in iedere sprint dezelfde type werkzaamheden uitvoert, kun je eenvoudig de velocity bepalen. De velocity is de ontwikkelsnelheid uitgedrukt in het gemiddeld aantal gerealiseerde punten per sprint.

Hiermee is een agile project eenvoudig aan te sturen en te plannen. Je hebt daarvoor 2 mogelijkheden:

  1. Vast budget en harde deadline
    Door het aantal resterende sprints te vermenigvuldigen met de velocity krijg je het totaal aantal punten dat nog gerealiseerd kan worden. Welke requirements dat zijn is voor de planning niet van belang en mag de business, net voor iedere sprint, bepalen. Dit werkt goed bij een waardegedreven aanpak, waarbij je een eenvoudige variant van het systeem steeds verder verbetert.
  2. De scope staat vast
    Als de opdrachtgever gegarandeerd alle (nu bekende) requirements wil inplannen (ondanks de wijzigingen die ongetwijfeld gaan komen), bereken je het totaal aantal sprints dat daarvoor nodig is. Dat doe je eenvoudigweg door het totaal aantal punten te delen door de velocity.

Ik ben benieuwd hoe jullie met de planning omgaan. Zet het alsjeblieft in het reactieveld hieronder en lees hoe andere organisaties hier mee omgaan.

Succes met de requirements,

Nicole de Swart

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

Gratis e-book Vliegende start als agile analist

e-book Vliegende start als agile analist Met 25 do's en dont's voor agile requirements

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

# abonnees

Abonneer je en ontvang eens per maand een nieuw artikel