De magische krachten van Velocity

velocity

“Hoe gaan we om met bugs in Agile? Krijgen bugs ook story points? Komen ze ook op de backlog?” Deze vragen krijg ik nogal eens als ik een Scrum training geef. Die vragen zijn gemakkelijk te beantwoorden als je een goed beeld hebt van Velocity.

Velocity is – mits goed toegepast – een bijzonder krachtig instrument in Agile projecten. De velocity is een maat voor de vaardigheid (capability) van een ontwikkelteam en geeft aan hoeveel story points per sprint kunnen worden gebouwd. Als je eenmaal je velocity weet, kan je goed voorspellen hoeveel user stories je in komende sprints kunt gaan realiseren.

Dat stelt wel de voorwaarde dat je de grootte van user stories inschat in story points. Story points schatten is eenvoudig. In de eerste sprint neem je de kleinste user story en stelt dat die user story een grootte heeft van 1 story point. Alle andere stories worden relatief ten opzichte van deze story geschat. Twee keer zo groot, vijf keer zo groot, enzovoorts. Planning poker is een prima methode om dit te doen met een groep. Later kan je, naast de ene story van 1 point andere stories aanwijzen als referentie-set. “Deze story is bij ons de referentie voor 5 punten, die voor 8”. Op die manier voorkom je de zogenaamde ‘story point inflatie’ en houd je de waarde van een story point stabiel.

De magische krachten van velocity uiten zich nu op de volgende manier. Als een team in een sprint niet erg succesvol was, en er bij het opleveren veel bugs gevonden werden, dan kan in een volgende sprint minder werk worden opgepakt. Er moet immers tijd vrijgemaakt worden om naast nieuwe stories te bouwen ook de bugs op te lossen. De gekozen velocity was blijkbaar te hoog, hoger dan de vaardigheid van het team. Met een lagere velocity krijgt het team in de volgende sprint automatisch meer tijd en rust om goed te ontwikkelen. Daardoor zullen er minder fouten worden gemaakt. De hogere kwaliteit van de software zal langzamerhand ook gaan leiden tot een hogere productiviteit waardoor op termijn de velocity weer kan stijgen.

Dit gaat natuurlijk alleen goed wanneer aan bugs géén story points worden toegekend. Ik kom dat soms nog wel eens tegen, maar daarmee help je het magische mechanisme meteen om zeep. Het feit dat, door bugs, de velocity zakt in nieuwe sprints is de terechte straf die je krijgt voor het maken van die bugs. Als je jezelf gaat belonen voor het corrigeren van bugs, door daaraan story points toe te kennen, komt nooit het feedback mechanisme tot stand dat zorgt voor ‘first-time-right’ development.

Het mechanisme werkt ook veel minder goed als je schat in uren in plaats van in story points. Een story point is een stabiele valuta, als je tenminste de goud-standaard van een referentie-set van stories goed bijhoudt. Een schatting in uren, of ideale uren, is veel minder stabiel. Als je de vorige keer 10 uur nodig had voor een story, en er later achter kwam dat er nogal wat bugs in zaten, dan zal je de volgende keer voor een soortgelijke story 12 of 13 uur gaan schatten. Het compensatie-mechanisme komt dan in de schatting zelf te zitten. Het mechanisme dat in de velocity zit wordt dan uitgeschakeld.

Dus: aan de slag ermee. Takenlijstje voor de volgende sprint:

  1. Schat de grootte van stories in story points. Begin met de kleinste story, schat grotere stories ten opzichte van die eerste. Bouw gaandeweg een referentie-set op;
  2. Schat de Velocity van het team. Dat kan de eerste keer prima door story points even om te rekenen naar uren. Na deze eerste sprint is die omrekening niet meer nodig, je hebt dan de behaalde velocity als basis;
  3. Stel aan het einde van de sprint vast wat de werkelijk behaalde velocity was, en gebruik die waarde als basis voor de volgende sprint. Compenseer eventueel voor de kwaliteit van het sprint resultaat, kies bij veel bugs een wat lagere velocity.

Overigens, als je planning poker wilt spelen kan je hier setjes kaarten bestellen!

Advertisements

About André Heijstek

Rijnlands / Agile verbeteren van software ontwikkeling
This entry was posted in Agile, Scrum, software engineering. Bookmark the permalink.

3 Responses to De magische krachten van Velocity

  1. Pepijn says:

    Sterk stuk. Ik neem wel aan dat het toepassen van een lagere velocity in een volgende sprint (t.g.v. te lage geleverde kwaliteit in de sprint ervoor en dus veel bug fixing) niet zonder slag of stoot aangenomen wordt door de product owner / opdrachtgever. Het team zal wat dat betreft “met de billen bloot” moeten. En hoewel in de voorgaande sprint dan software is opgeleverd die werkt en waarde toevoegt voor de klant, kan ik me voorstellen dat een lagere velocity in een volgende sprint een lastige boodschap is…

    • Hans Bernink says:

      André,
      Dit is allemaal niets nieuws. Oude wijn in nieuwe zakken. Maar oude wijn is wel het kwaliteitsspul waar het om draait natuurlijk!
      Het komt allemaal neer op de basis kostendrivers achter een willekeurig change traject. Dat is natuurlijk de core metrics / duivelsdriehoek: Size (voor scrum in story points), Duration (voor scrum fixed sprint duur), effort (voor Scrum fixed level-load sprint team * sprint duur), kwaliteit (aantal bugs), en de productiviteit (voor scrum: velocity).
      Zoals bekend bij de duivelsdriehoek kun je niet alles tegelijk instellen, als je op één punt druk zet, zul je op een ander punt moeten inleveren.
      Dus als de produktiviteit (velocity) van het team te laag is, en de size, tijdsuur en de bestede effort blijft gelijk, dan kan het niet anders dan dat je inlevert op kwaliteit.
      De oplossing is ook even klassiek: Bij scrum blijft de duur (sprintduur) constant, de effort ook, en vooralsnog de productiviteit van het team ook. Je houdt dus 2 parameters over: size en kwaliteit. Dus als de kwaliteit omhoog moet, moet de size omlaag: minder story points in de volgende sprint. Dit blijft zo totdat de inherente productiviteit van het sprintteam verbeterd is.
      Het wordt dus vooral tijd dat management – ook van scrum projecten – deze oude wijsheden gewoon gaat toepassen.
      Zonde om al die geweldige oude wijnen zo te laten liggen verkommeren, en je business klanten voortdurend op te zadelen met het nieuwe bocht. 🙂

  2. Hoi Hans,
    Leuk om weer eens iets van je te horen!
    Ik ben het deels wel met je eens, in Scrum/Agile zit heel veel oude wijn verpakt, vaak met een nieuwe naam die het wat aantrekkelijker maakt. En de nieuwe verpakking zorgt op dit moment vaak voor toepassing van goede oude principes. Principes die in de meeste waterval projecten niet werden toegepast. Dus tot zover alleen maar winst.
    De mooie bijbelse uitdrukking ‘oude wijn in nieuwe zakken’ heeft echter een negatieve connotatie. De oude wijn zorgt ervoor dat de nieuwe zakken gaan scheuren en daarmee gaat de mooie wijn verloren. En drankmisbruik willen we natuurlijk voorkomen 😉
    De vraag is of dat hier ook geldt. Ik denk van niet. Juist de combinatie van deze goede oude principes met wat nieuwe ideeën (met name korte sprints) zorgt voor een combinatie waarin alles tesamen zeer goed functioneert. Jurgen Appelo heeft daar een mooie blog over geschreven, waarin hij de combinatie als memeplex beschrijft. Ik ben benieuwd wat je daar van denkt.
    http://www.noop.nl/2010/02/the-success-of-the-agile-memeplex.html
    Ik heb overigens wat andere ideeën over Kerst dan Jurgen. Maar de rest van de blog is zeer de moeite waard.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s