Velocity

Velocity

In Intermediate, Scrum by PeterLeave a Comment

Leestijd: 4 min.

Velocity

Velocity wordt berekend door aan het einde van de Sprint het opgeleverde werk in Story punten te bepalen. Dit doe je door van alle volledig opgeleverde User Stories het aantal Story punten op te tellen.

Velocity is een metric die gehanteerd wordt om de hoeveelheid werk die een team aan kan in één Sprint te kunnen bepalen. Velen zien Velocity als een van de belangrijkste metrics binnen Scrum. Zowel om de ontwikkeling van het team in opeenvolgende periodes te kunnen bepalen, maar ook omdat het zo een handig hulpmiddel is tijdens de Sprint Planning meeting.

Velocity is wellicht de bekendste Agile metric. Het is vermoedelijk ook de meest onjuist gebruikte en overgewaardeerde metric binnen Agile werken.

Hoe bereken je Velocity op de juiste manier?

Voor de duidelijkheid. Alleen Story points tellen die in de ‘Done’ kolom staan aan het eind van de betreffende Sprint, controleer nog wel even of ze voldoen aan de Definition of Done. Wat heel belangrijk is, is dat alleen volledig afgeronde Stories tellen. Dat je alleen punten telt als de Story in de afgelopen Sprint volledig is afgerond en zeker niet relateert aan wanneer deze is gestart. Vaak zullen de Stories op voorhand zo klein worden gemaakt dat ze in een Sprint afgerond kunnen worden, dat is altijd de beste keuze. Soms is dat echter niet mogelijk of niet gelukt. Dan val je terug op bovenstaande: alleen volledig afgeronde Stories tellen.

Even een voorbeeld. Stel een Story met 5 punten is gestart in Sprint 6 en deze was aan het einde van Sprint 6 voor 80% klaar. Dat zijn dus nul punten voor deze User Story in deze Sprint. Je mag absoluut geen deelpunten toekennen voor 80% klaar, je mag dus geen 4 punten toekennen in dit specifieke voorbeeld.

In Sprint 7 is de Story klaar. Dan tel je 5 punten, mits het opgeleverde werk voldoet aan de Definition of Done. Blijf hierin consistent, anders heb je niet veel aan deze metric.

Een andere fout die je niet mag maken is deze punten pas te tellen als het werk wordt opgeleverd aan de klant.  Want hier bestaat de mogelijkheid dat een Stakeholder en/of Product Owner besluit om het opgeleverde werk pas later aan de klant ter beschikking te stellen. Dit is vanzelfsprekend niet ideaal, want het creëert ‘waste’, maar daar gaat het nu tijdens deze uitleg even niet om. De punten worden toegekend als de Story ‘done’ is, omdat je wilt bijhouden hoeveel werk een team kan afronden binnen een gegeven periode tijd. Niet hoeveel of hoe vaak (software) wordt opgeleverd aan de klant.  

Waarom Velocity?

Een van de fijnste redenen om Velocity bij te houden is om teams met elkaar te kunnen vergelijken. Een team met een Velocity van 12 is minder goed dan een team met een Velocity van 10.

Ik hoop dat je erg geschrokken bent van bovenstaande stelling! Want dit is dit een denkrichting die heel vaak terugkomt. Dit is geen agile denkrichting, maar ‘ouderwets management denken’. Velocity mag nooit gebruikt worden om de ‘performance’ van een team te vergelijken.

Velocity is namelijk geen metric om effectiviteit, efficiency, competentie of whatever tussen teams of met anderen te vergelijken. Het is slechts een cijfer die weergeeft hoeveel vraagstukken binnen een bepaalde tijd worden omgezet in geteste software of product toevoegingen. Het mooiste is nog wel dat er honderden redenen kunnen zijn waarom een team een bepaalde Velocity heeft, maar dat het merendeel van deze redenen helemaal niets te maken hebben met bijvoorbeeld hoeveel ervaring er is in het team.

De risico’s van Velocity

Het eerste risico van Velocity is dit cijfer onjuist te gebruiken. Het cijfer verstrekt het team een benchmark om goed te kunnen plannen. Door een juiste inschatting te maken van hoeveel werk kan worden gedaan binnen een gegeven tijdsperiode. That is it! Maar lees het volgende eens….

Geen openheid of respect

Er gaan veel stemmen op om de velocity nooit aan buitenstaanders mede te delen, dus ook niet aan de manager. Helaas is dit niet open, maar dit gedrag is veelal gebaseerd op eerder getoond gedrag van belanghebbenden. Deze zien Velocity als een efficiency tool!

Als een buitenstaander het vraagt,vraag je minimaal waarom diegene het wilt weten, als het antwoord is: ‘om te vergelijken’ moet je dit eerst met het team overleggen. Als het antwoord is ‘omdat ik wil weten wanneer het werk klaar is’ dan is het open antwoord: wanneer je verwacht dat het klaar is. Ook hier geldt vanzelfsprekend dat alle Scrum Values volledig van toepassing zijn. Naast openheid is er ook respect nodig.

Kwaliteit en value?

Het tweede risico. Velocity zegt helemaal niets, nul, nada over kwaliteit of value (waarde). Kwaliteit en Value? Dat zijn toch twee hele belangrijke zaken en daar zegt het meest gebruikte metric van Scrum helemaal niets over. Velocity gaat namelijk eigenlijk alleen over hoeveel Story punten er van links naar rechts op het bord zijn gegaan.

Een goed gesprek behoort te gaan over klant verwachtingen en hoever de opgeleverde Story punten hieraan tegemoet komen. Is het leven van de afnemer echt beter geworden, of zijn we trots op onze nieuwe functionele of niet-functionele testen en benchmarks. Kortom, de klant interesseert het geen zier hoeveel Story Points er zijn gerealiseerd. Het gaat de klant om kwaliteit en waarde!

Dus wil jij een team beoordelen of vergelijken met behulp van het velocity cijfer? Dan beoordeel je ook de belangrijkste zaken niet.

Maar ken je deze risico’s van Velocity ook?

Alleen het team kan bepalen hoeveel Story Punten er worden gegeven aan een Story. Als Velocity een te belangrijke graadmeter is dan krijgt elke Story minimaal 100 Points! Nu zijn wij voortaan de beste! Kortom, er ontstaat iets wat je mag beschouwen als een ongewenste situatie. En dat ontstaat omdat een cijfer onjuist gebruikt wordt.

Story points zeggen normaliter iets over moeilijkheidsgraad en complexiteit. Stel het team kiest om een item uit te werken met veel Story punten, want het andere team scoort vaker een hogere Velocity. Het team ‘scoort’ 35 punten voor iets wat de klant totaal niet interesseert. Het team geeft trots aan dat er een een top Velocity ‘score’ is neergezet! Maar liefst 35 punten i.v.m. de moeilijkheidsgraad en complexiteit! Veel meer dan het andere team.

Dat doet mij echter helemaal niets, ik denk namelijk dat jij ook veel liever 10 Story Points ziet die echte waarde leveren voor de klant.

Hoe gebruik je Velocity veilig?

Veel Scrum Masters kiezen er voor om een voortschrijdend gemiddelde te hanteren van de 3 achtereenvolgende sprints. Dit is wellicht het meest betrouwbare cijfer om de mogelijkheden voor de komende Sprint goed te beoordelen. De hoogte- en dieptepunten worden statistisch gezien enigszins afgevlakt.

Hou vooral in de gaten dat veranderingen in team, omgeving, Stakeholders, Product, Product Owner veel impact kunnen hebben op de Velocity. Het is dus raadzaam om de team Velocity slechts voor een paar Sprints te gebruiken. Dit doe je vooral als je een Burnup of Burndown Chart gebruikt. Dan visualiseer je de Velocity met de laatst bekende gemiddelde.

Een alternatief hiervoor is Story Throughput, deze gebruik je als Story Points alleen gebruikt worden om voorwaarts te plannen. Deze behandel ik later een keertje.

Leave a Comment