Schatten in een Agile wereld

Inschatten wat de kosten moeten zijn is lastig. Vaak wijzen mensen in een agile omgeving op de driehoek Scope, Resources en Schedule. Je kunt niet Scope (wat je bouwt), Resources (wat je ervoor nodig hebt) én Schedule (de planning) vastzetten. Wanneer je Scope en Schedule vastzet kun je er wellicht extra geld tegenaan gooien. Op eenzelfde manier kan er ook voor gekozen worden om juist de planning los te laten en/of de scope. Alle drie zaken zeker en vast gaat niet. Maar toch, we willen een idee: wat gaat het kosten en wanneer is ‘het’ (het geplande) af?

Planningspoker

Scrummers doen hun schattingen met het spelen van planningspoker. Deelnemers aan een planningssessie werpen kaarten op tafel waarmee ze uitdrukking geven aan hoe zwaar ze een taak achtten t.o.v. een referentietaak met kaarten die genummerd zijn volgens de Fibonacci(-achtige) reeks. De grotere getallen liggen verder uit elkaar en geven daarbij ook uitdrukking aan een grotere mate van onzekerheid.

Je kunt echter pokeren op meerdere niveaus: je kunt pokeren over de grootte van het gehele project. Maar je kunt ook gaan planningspoker spelen voor ieder klein deeltaakje.

Welke deeltaken? #BDOF?

Te vaak heb ik gezien dat er urenlang, soms dagen achtereen, in kamers wordt gepland. Eigenlijk verwordt het plannen daar tot een grote designsessies met het hele team. Best wel ‘big’ om mee te beginnen. Weinig ‘lean’ in ieder geval, want er wordt niet alleen gesproken over de complexiteit van een feature, maar in ook over alle taken die nodig zijn om die feature te bouwen. En vervolgens wordt er taak voor taak geschat. Dat kan sneller en wendbaarder.¹

Schatten doe je op story niveau

Het idee van userstories uit Scrum vind ik een zeer verhelderende: een kort beschreven extra stuk functionaliteit. Met duidelijk wat het moet doen en voor wie en waarom. Het is de juiste mix tussen globaal en specifiek. Ik schat graag alleen op dit niveau. Soms onderschat je, soms overschat je, maar uiteindelijk leer je wat een schatting waard is (of anders gesteld: welk bedrag je aan de schatting zou moeten hangen).

Complexiteitspunten

In Scrum wordt gesproken over storypoints. Ik heb enkele jaren geleden mijn communicatie aangepast en spreek liever over complexiteitspunten. Complexere stukken software kunnen niet door iedereen gebouwd worden en/of kosten simpelweg meer tijd om te realiseren. Per punt wordt een vast tarief gehanteerd, een tarief dat ik in de loop der tijd vanzelfsprekend heb getuned. Design (zowel technisch als basis interface) zit in het pakket en wordt mijn risico, maar ik hou er dan ook niet van om dagen te rekenen aan een offerte waar de klant mogelijk het geld niet voor over heeft. De klant krijgt daarbij van mij geen exacte planning, maar wel waar de klant zich vaak het drukst om maakt: een duidelijke vaste prijs met een duidelijk en conform de specificaties (en dat is bij murb natuurlijk altijd een gebruiksvriendelijk) werkend eindproduct.

¹ Volgens mij is het in de strikte zin van Scrum ook niet zo dat er in het begin al zou moeten worden geschat op taakniveau, maar is het bedoelt als een vorm van validatie aan het begin van een sprint of de eerdere globale schatting klopt. Al is het al een beetje achter de feiten aanlopen, je hebt immers de commitment al gegeven aan die set aan te bouwen features, kan het helpen om de organisatie verder op al tijdig te informeren dat het mogelijk een optimistische schatting was.