SCRUM, budgetteren is beter dan schatten

Het idee van flexibel budgetteren staat haaks op het maken van gedetailleerde inschattingen. Veel bedrijven lopen in een valkuil wanneer ze aandringen op het inschatten van de werkzaamheden. Het typische verhaal is dat iemand de vaste opleverdatum wil weten voor een groot project. De projectscope splitsen we dan op in kleine, gedetailleerde user stories. Die bespreken en schatten we vervolgens en die schattingen tellen we dan maar op. Maar levert dit wel de exact opleverdatum op?

Het inschatten van onzekerheid

We zijn doodsbang voor onzekerheid. We hebben liever ongelijk dan dat we onzeker zijn. Dit is het begin van het probleem. Een mooie exacte einddatum voelt goed, het voelt alsof iemand de touwtjes in handen heeft. Het uitgangspunt van dit proces is echter onjuist. Schattingen hebben namelijk een foutenmarge en die heroverwegen we maar zelden. Bij het gewoon optellen van getallen houden we geen rekening met de samengestelde effecten van die fouten. Hierdoor is het eindresultaat wel precies, maar ook vreselijk fout.

Er zijn verschillende technieken voor foutvermindering.

• Het schatten met betrouwbaarheidsintervallen.
• Schattingen op basis van statistische gemiddelden.

In veel gevallen is dit eigenlijk niet het probleem. Lange termijn schattingen geven ten onrechte het gevoel van precisie en zorgen voor een langdurig engagement voor de einddatum van een project.

Het budgetteren van een groter project

Probeer eens niet te schatten, experimenteer eens met het budgetteren van een groter project. Zowel voor de kosten als voor de tijd. Het budget zal een beperking voor de gewenste functionaliteit vormen. In plaats van te vragen “hoe lang duurt het?”, komt de vraag “wanneer heb je het nodig?” En “hoeveel geld heb je te besteden?”

Het scrumteam moet dan een oplossing bedenken die aan de gewenste functionaliteit voldoet. Dit vereist uiteraard transparantie en vertrouwen tussen de mensen die software leveren en hen die daarvoor betalen. Deze aanpak is veel gemakkelijker voor interne teams dan voor levering door derden.

De voordelen van budgetteren

Door te budgetteren, hoeven we geen kleine schattingen op te tellen. De definitieve doorlooptijd is immers al bekend. Dit elimineert de noodzaak om grotere mijlpaal in kleine stories op te splitsen en deze vooraf te analyseren. Dit voorkomt dat tijd wordt verspild aan onnodige analyses en vermijdt een sterke focus op een einddatum. In plaats daarvan komt een afspraak voor het leveren van bedrijfswaarde.

Een ander belangrijk voordeel is dat deze aanpak extra ontwerpbeperkingen oplegt. Daardoor komt het scrum-team met oplossingen die passen binnen de business case. Op basis van een budget moeten we bepaalde oplossingen improviseren. Andere oplossingen zullen echter wel aan de eisen (moeten) voldoen.

Hoe laten we budgetteren voor ons werken?

Een belangrijk aspect om dit goed te laten werken is om duidelijk te communiceren dat we het budget niet volledig hoeven te besteden. Ideaal gesproken zou het projectteam met een snellere, goedkopere oplossing moeten komen dan het totale budget.

De beste manier om tijd en geld te begroten, is door naar de te verwachten opbrengst te kijken en de waarde daarvan te vragen aan belanghebbenden. Het financiële budget kunnen we dan neerzetten als een percentage van de vastgestelde waarde. We budgetteren dus op basis van de return-on-investment.

De waarde van software inschatten

Helaas kunnen veel bedrijven de waarde van een stuk te bouwen software niet schatten. Dit is gevolg van een zeer lange ROI termijn of een onzekere markt waar zij inzetten. In zekere zin is het niet kunnen schatten van de waarde een argument tegen gedetailleerde opleverschattingen. Het is vreemd dat mensen die om een ​​precies aantal opleverdagen vragen, zelf de waarde niet precies kunnen bepalen. Terwijl dat veel belangrijker is.

Een unitmanager in het openbaar als dom neerzetten omdat hij de waarde niet kan kwantificeren, is niet de beste stap om vertrouwen te creëren.

Wanneer er geen goed waardemodel is, probeer dan de volgende twee benaderingen:

• Vraag naar uitersten.
• Budgetteer incrementeel.

Uitersten

Mensen praten vaak gemakkelijker over uitersten dan over precieze waarden. Vraag bijvoorbeeld naar extremen:

• Wat moet deze software minimaal opbrengen om een ​​redelijk effect te hebben?
• Wanneer zou iedereen later zeggen dat dit project de moeite waard was?

Dit helpt vaak om een ​​goede discussie te openen. Zelfs orden van grootte zijn een goed startpunt voor de discussie. Dit werkt ook voor werken onder tijdsdruk. Interessante vragen die we kunnen stellen zijn bijvoorbeeld:

• Wat is het laatste moment dat we kunnen lanceren, om nog steeds waarde uit de software te halen?
• Hoe snel kan je de software in gebruik nemen als die nu beschikbaar zou zijn?

Als de extremen redelijk dichtbij elkeer liggen, kunnen we het doelwit ergens in het midden plaatsen. Als ze ver uit elkaar liggen, kunnen we eerst naar het laagste waarde streven. Zodra die waarde is bereikt, kunnen we opnieuw plannen voor een hogere impact.

Maak deelprojecten als de onzekerheid blijft

Als de discussie over de uitersten doodloopt, is er geen gedeeld begrip over de potentiële waarde. Dit betekent vaak dat het project onzeker is. In dergelijke gevallen is de volgende stap het verminderen van die onzekerheid. In plaats een te beslissing te nemen over het volledige budget kunnen we stapsgewijs plannen.

We kunnen butgeteren voor:

• Opleiding.
• Het maken van prototypes.
• De Scrum test cyclus met gebruikers.
• Bedrijfsprocessen half-handmatig automatiseren.
• Management terug naar de tekentafel sturen om een ​​gedeeld waardemodel te bedenken.

De scope van deelprojecten is vaak gemakkelijker te bepalen en te verdedigen. Iedereen weet toch dat dit niet de uiteindelijke oplossing zal zijn. Zodra de resultaten van de deelprojecten de onzekerheid over het grotere doel verminderen, kunnen we stapsgewijs investeren in het einddoel. Hoe meer onzekerheid er is, hoe kleiner de deelprojecten moeten zijn.

Als het waardemodel relatief lineair is zullen kleine deliverables snel nieuwe waarde aan het bedrijf kunnen toevoegen.

Budgetteren in een SCRUM omgeving

Bedrijven die starten met SCRUM voelen zich vaak onzeker met betrekking tot het maken van begrotingen. Je wil immers een budget in de boeken zetten en weten wat je er voor krijgt. Bij SCRUM is dat wat lastiger omdat je bij de ene sprint nog niet weet wat je in de volgende gaat doen. Ook het aantal sprints en daarmee de looptijd van het project zijn meestal nog niet helder bij de start.

Bij het samenstellen van een sprint kijken we in de backlog en kiezen we die user stories die het meeste waarde toevoegen en goed aansluiten. Tevens zijn de requirements voor die stories meestal al goed uitgewerkt.

Door een scrum-project te budgetteren zoals in dit artikel is omschreven bakenen we het project goed af. Iedere sprint en user story houden we goed tegen het licht. We bepalen of de geplande functionaliteit wel binnen de budgetdoelstellingen past.

Dit levert het volgende resultaat:

• Sommige user stories werken we minder diep uit en kosten minder.
• Project blijft binnen het budget en is goed te begroten.

Discussieer mee op LinkedIn.