Een veel gestelde vraag binnen Agile teams is: ‘hoe om te gaan met het creëren van voorspelbaarheid?’. Omdat Agile vaak toegepast wordt binnen een complexe en onvoorspelbare omgeving, werken absolute schattingen vaak niet en kan het een goede stap zijn om dit relatief te doen. Maar wat houdt dit nu in?

RELATIEF vs EXACT schatten
Stel je eens voor hoeveel km² Nederland is en stel je hetzelfde voor bij Spanje. Het is moeilijk daar exact antwoord op te geven. Als ik je vraag hoeveel keer groter Spanje is ten opzichte van Nederland dan weet je waarschijnlijk beter het antwoord te schatten. Hetzelfde geldt voor het bepalen hoe hoog gebouw X en Y exact zijn, relatief ten opzichte van elkaar zal een stuk beter gaan. Conclusie, exact schatten kunnen wij als mensen niet. Relatief schatten daarentegen een stuk beter!

Bij het inschatten van werk geldt hetzelfde principe. Hoeveel werk iets precies gaat zijn is onduidelijk, omdat onze context complex en onvoorspelbaar is en we dus moeite hebben exacte schattingen te geven in tijd/complexiteit. Echter kunnen we vaak wel van stukjes werk aangeven hoeveel het relatief ten opzichte van elkaar ongeveer zal zijn.

Bovenstaand is de reden waarom Scrum teams vaak gebruik maken van relatieve schattingen om hun werk op de Product Backlog in te schatten.

Wat is het doel van relatief schatten?
Ondanks dat de wereld complex en onvoorspelbaar is, is er binnen (software) ontwikkeling wel behoefte aan een mate van voorspelbaarheid. Je kan immers niet zonder enig idee en gevoel oneindig door blijven gaan met productie. Relatief schatten draagt eraan bij een betere forecast te kunnen geven door te kijken naar eerder geleverd werk en daarvan te leren. Teams hebben, doordat we beter zijn in relatief schatten, een realistischer beeld van wat ze in een Sprint hebben gebouwd en in de toekomst aan zullen kunnen. Dit helpt de Product Owner bij zijn communicatie richting stakeholders (wat kunnen ze wanneer verwachten) en het team bij het inschatten van een forecast van werk wat ze (naar inzicht op dat moment) af kunnen ronden.

Waarom niet schatten in tijd?
Nu komt de grootste valkuil: in de meeste gevallen wordt in eerste instantie uitgegaan van relatief schatten ten opzichte van elkaar enkel op basis van tijd. Dus, hoelang werk ik aan feature/Product Backlog item X ten opzichte van Y. De valkuil bij schatten in tijd is echter dat dit lastig is te benoemen. Er kan gedacht worden dat werk weinig tijd zal kosten om af te ronden, maar vanwege de complexe omgeving van software ontwikkeling is de onvoorspelbaarheid groot en is de tijd exact dus niet kloppend. (Denk bijvoorbeeld aan de (snelle) verandering van technologie, verstoringen, afhankelijkheden of onverwacht werk wat uit testen naar voren komt).

Vandaar dat het beter zal werken om te schatten in een combinatie van complexiteit en effort (hoe moeilijk is het en hoeveel werk is het). Dit omdat het bouwen van nieuwe software, zoals al eerder aangegeven, vaak complex is (een nieuwe feature is niet repeterend, en dus kunnen we niet op basis van eerdere ervaring met deze exacte feature bouwen een voorspelling doen).

Complexiteit en effort brengen onder andere risico, onzekerheid (je weet niet wat je allemaal niet weet), inspanning, schattingen, onvoorspelbaarheid met zich mee. Je kan niet voorspellen hoelang je bezig gaat zijn met het bouwen van een nieuwe feature, omdat je te maken zal hebben met onvoorziene omstandigheden. Met die onzekerheden in gedachte zal je dus gaan schatten.

Mocht er te veel onzekerheid zijn dan zal extra onderzoek hiernaar kunnen helpen een beter beeld te creëren van het vraagstuk (Refinement).

Relatief schatten is dus een hulpmiddel om voorspelbaarheid (een verbeterde forecast) te creëren in een complexe omgeving en helpt bij Empirische (proefondervindelijk) ontwikkelingen door leringen uit het verleden.

Bovenstaande vraagt oefening en ervaring. Ga ermee aan de slag, voer de juiste gesprekken met je team en leer van het verleden!

Ik hoop dat deze blog heeft geholpen een verhelderd beeld te creëren over de gedachte achter relatief schatten. Een voorbeeld van hoe het in praktijk kan worden uitgevoerd met behulp van Planning Poker zal in een volgende blog worden uitgelegd.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*