De onzekerheidskegel bij agile schattingen

Uw vroegste schatting is uw slechtste — en dat is een eigenschap van het werk zelf, geen tekortkoming van het team. De onzekerheidskegel is de reden waarom u niet langer één enkel getal moet eisen voor iets waaraan nog niemand is begonnen.

De kegel is een eenvoudige observatie met ingrijpende gevolgen: aan het begin van een project is het verschil tussen uw schatting en de werkelijkheid enorm, en dit verschil wordt kleiner naarmate u meer leert. Barry Boehm ontdekte deze vorm in gegevens over softwarekosten; Steve McConnell gaf er een naam aan. In een grafiek over de tijd gezien lijkt het op een kegel — breed aan de linkerkant, waar u het minst weet, en versmallend tot een punt aan de rechterkant, waar het werk bijna voltooid is en er niets meer mis kan gaan.

Waarom dit van belang is voor het maken van schattingen

De meeste problemen bij het maken van schattingen komen voort uit de eis om een puntschatting te geven op het breedste deel van de kegel. Iemand vraagt „Hoe lang zal het nieuwe factureringssysteem in beslag nemen?“ nog voordat er ook maar één regel code is geschreven, krijgt als antwoord „ongeveer drie maanden“ en beschouwt dit als een vaste toezegging. De kegel geeft aan dat dit getal in werkelijkheid ergens tussen de zes weken en negen maanden ligt — en door te doen alsof dat niet zo is, wordt de teleurstelling alleen maar naar een later tijdstip verschoven.

Dit is precies de reden waarom bij agile de relatieve omvang wordt ingeschat in plaats van dat er vastgelegde deadlines worden gegeven. Story points en planning poker gaan niet in tegen de ‘cone’ — ze accepteren deze. Een snelle relatieve inschatting („dit is omvangrijker dan wat we tijdens de vorige sprint hebben opgeleverd“) is de maximale precisie die in een vroeg stadium eerlijk kan worden geboden, en velocity zet dat om in een prognose met een marge in plaats van een valse belofte.

Hoe u de kegel smaller kunt maken

De kegel wordt smaller wanneer u onbekende factoren wegneemt — niet wanneer u een buffer toevoegt. In volgorde van invloed:

• Spike: de meest risicovolle onbekende factor. Een spike met een vast tijdsbestek levert informatie op, en dat is het enige wat de spreiding daadwerkelijk verkleint.
• Blijf verfijnen totdat er geen vragen meer zijn. Een verhaal waarover het team steeds weer vragen stelt, bevindt zich aan de brede kant van de kegel; scherpe acceptatiecriteria trekken het naar rechts.
• Verdeel het. Kleinere verhalen bevinden zich lager in de kegel — elk onderdeel is duidelijk, waardoor elke schatting nauwkeuriger is dan één enkele schatting voor het geheel.
• Pas uw inschatting aan wanneer u iets hebt geleerd. Uw inschatting bijstellen naarmate het zoekgebied kleiner wordt, is eerlijk; dit doen om een doel te halen, is dat niet.

De kegel is geen excuus om de cijfers op te krikken

De verkeerde conclusie is: „Alles is onzeker, dus verdubbel elke schatting.” Door de schattingen op te krikken, verschuift de hele kegel naar boven zonder dat deze smaller wordt — u blijft gissen, maar dan op een pessimistische manier. De juiste reactie op een brede kegel is ofwel de onzekerheid weg te nemen (spike, verfijnen, opsplitsen), ofwel het bereik eerlijk te communiceren en toe te zeggen dat u de schatting opnieuw zult maken.

Veelgestelde vragen

Wat is de onzekerheidskegel?

De onzekerheidskegel beschrijft hoe de spreiding van een schatting aan het begin van een werkopdracht het grootst is en steeds kleiner wordt naarmate het werk vordert en onbekende factoren worden opgehelderd. In een vroeg stadium kan een schatting in beide richtingen aanzienlijk afwijken; tegen de tijd dat er voldoende inzicht in het werk is verkregen, vernauwt de spreiding zich tot het daadwerkelijke resultaat.

Wie heeft het concept van de ‘kegel van onzekerheid’ bedacht?

Deze vorm werd voor het eerst door Barry Boehm in het begin van de jaren tachtig waargenomen als een verband tussen software en kosten, en Steve McConnell noemde het later de „onzekerheidskegel” en maakte het begrip populair binnen agile en bij software-inschattingen.

Hoe is de ‘cone of uncertainty’ van toepassing op agile schattingen?

Dat is de reden waarom bij agile de relatieve omvang wordt ingeschat in plaats van vooraf vast te leggen op welke data iets klaar moet zijn. Bij story points en planning poker wordt ervan uitgegaan dat vroege schattingen ruw zijn; men verruilt valse precisie voor een snel relatief beeld en voert nieuwe schattingen uit naarmate het werkgebied zich door verfijning, spikes en opgeleverde werkstukken verder toespitst.

Hoe kunt u de onzekerheidsconus verkleinen?

U vult het niet aan — u lost de onbekende factoren op die ervoor zorgen dat het breed is. Ga gericht te werk op het meest risicovolle deel, verfijn het verhaal totdat er geen vragen meer zijn, splits het op zodat elk onderdeel begrijpelijk is, en maak een nieuwe schatting zodra u iets hebt geleerd. De kegel wordt smaller wanneer onzekerheid wordt weggenomen, niet wanneer het cijfer wordt opgeblazen.

Aanbevolen lectuur

• Relatieve versus absolute schatting — waarom relatieve maatbepaling de ‘cone’ overleeft.
• Het opsplitsen van user stories — spikes en splits: de stappen waarmee informatie wordt verkregen die het bereik verkleint.
• Velocity — het omzetten van een vroege, ruime schatting in een prognose met een bandbreedte.
• Handleiding voor agile schattingen — het volledige overzicht van schattingsmethoden.
• Gratis Planning Poker voor agile teams — bekijk hier de korte uitleg die de ‘cone’ vereist.