De letterlijke vertaling van velocity is “snelheid”. Binnen Scrum gaat het hier vooral om de gemiddelde hoeveelheid werk die een team in een sprint kan afronden. Het helpt enorm bij de planning van een project als je daar een goed beeld van hebt.
Hoe werkt dit nu in Agile werken, en met name in het werken binnen de sprint? En waarom zou je geen normale watervalaanpak hebben?
Om maar even met de waterval aanpak te beginnen, bij deze aanpak werk je met een totaaloverzicht over het totale project. Je werkt hierbij vaak met uren en weken. Dit werkt uitstekend voor projecten die goed voorspelbaar zijn, projecten waarbij begin en eind niet veel afwijken van de verwachtingen en de klant tussendoor geen extra beslissingen hoeft te nemen. Stakeholders voelen zich hier vaak erg goed bij, want je doet een voorspelling over hoeveel werk je zult gaan doen, en weet dat het in die richting zal komen.
Scrum, daarentegen, is bij uitstek geschikt voor complexe projecten waarbij er vaak niet meer bekend is dan een stip op de horizon. Het probleem hier: als de klant niet weet wat hij precies nodig heeft, hoe moeten we dat dan precies maken? We zullen dus gedurende het project in nauwe afstemming met de klant tot de gewenste invulling moeten komen. Als we hierbij zouden gaan werken met waterval, dan zouden we heel vaak alles weer moeten aanpassen.
Daarom baseren we de inschattingen in Scrum op wat de developers weten van hun vak, op hun werkelijke ervaringen uit het verleden. En daar komt het: om de ervaringen zo zuiver mogelijk op papier te krijgen werken we het liefst niet met uren of dagen, maar met een relatieve meeteenheid, punten. Veel teams werken hiervoor met planningspoker kaarten of een app. De punten die hierop staan zijn gebaseerd op de Fibonacci reeks.
Deze werkwijze past erg bij empirisme, om een rekeneenheid en rekenwijze te kiezen die uitnodigt tot discussie met anderen. Bij relatief inschatten schatten we iets in ten opzichte van iets wat we al kennen uit het verleden. Je schat dan dus niet de hoogte in van een gebouw in meters, om maar een voorbeeld te noemen, maar je bekijkt hoeveel groter of kleiner het is dan het gebouw ernaast. En daarvoor gebruik je punten. Dus als dit gebouw A nu 13 punten hoog is, hoe groot is gebouw B dan?
Wat is hier het nut van? Welnu stel je eens voor dat we de Product Backlog aan het refinen zijn. In een team met developers steekt de meest ervaren developer van wal en zegt over een deel van het werk wat op de product backlog staat, dat hij daar ongeveer een half uur over doet. De developer die net nieuw binnen is bij de organisatie besluit daarop wijselijk zijn mond te houden en geen commentaar te geven, en de collega’s denken alleen maar: “Dan doe jij het maar zelf, want zo snel kan niemand dit ”.
Wat zie je hier: Als je inschat in uren of dagen, dan leidt dat snel tot een waardeoordeel. Het leidt tot emotie, in het beste geval tot verlegenheid, en bescheidenheid maar soms ook tot haantjesgedrag en nog veel meer. Leren van elkaar, en leren van ervaringen uit het verleden worden dan erg moeilijk. Een echte discussie komt er dan niet, terwijl wat je echt wilt weten is: kennen we dit? In onze gezamenlijke ervaring, hoeveel moeite is dit echt? Wat moeten we terughalen over eerdere projecten, en hoe kunnen we daaruit leren?
In empirisch werken is dit nu precies hoe we ons steeds verbeteren. Het levert beter teamwerk op. Het team leert elkaar steeds beter kennen door deze discussies en er ontstaat een steeds groter vertrouwen in wat het team samen kan. Want een ding is zeker, alleen over dat wat geweest is, kun je zekerheden ontlenen. En wat je zeker weet, kun je gebruiken als inschatting voor de komende tijd.
Je moet om met velocity te kunnen werken al het werk wat op de product backlog staat op deze wijze inschatten. Wat heel belangrijk is, is om de toekenning van de story points aan de teams zelf te laten. Daarmee is het mogelijk dat deze van team tot team nogal uiteenlopen—en deze punten kunnen dus nooit gebruikt worden om de teams met elkaar te vergelijken.
Ook kan de hoeveelheid punten die behaald wordt nogal verschillen per sprint. Kijk hier vooral ook naar zaken als ziekte, vrije dagen, de complexiteit van het werk van deze keer—en dat het verschilt is dus normaal, en geen ramp.
De gemiddelde velocity wordt daarom over een aantal afgeronde sprints berekend; dit geeft vrij aardig weer hoeveel werk het team de komende periode zal gaan verzetten. Hoe langer een team samenwerkt, hoe beter dit voorspelbaar wordt.
Zo kun je na een aantal sprints dus een goede voorspelling doen over hoeveel werk het team kan verzetten. En je kunt ook een goede voorspelling doen over hoeveel sprints een team nodig zal hebben om een project af te ronden. Daardoor kun je, zelfs met een veranderende scope, op tijd signaleren of het haalbaar is om alles wat in de product backlog staat op te leveren binnen de gegeven tijd en het beschikbare budget.