Tim van der Meel

Tim van der Meel

Scrum Master

Velocity, misbruik het niet!

Velocity is een manier om de hoeveelheid werk te meten welke een team kan verrichten gedurende een sprint. Dit wordt gemeten door de inschattingen van de totaal aantal afgeronde user stories bij elkaar op te tellen aan het einde van de sprint.

Het meten van velocity is een gemeengoed binnen Scrum. Het werd gedaan in bijna alle teams waarmee ik tot nu toe heb mogen samenwerken. In veel gevallen ben ik er voorstander van. Het is een geschikt hulpmiddel voor het development team om in te schatten hoeveel werk kan worden verricht gedurende een sprint. Met deze informatie kunnen voorspellingen worden gedaan over wanneer een ‘done increment’ opgeleverd en in gebruik kan worden genomen.

Ik heb een manager meegemaakt die met een simpele rekensom had gehoopt velocity bij te kunnen ‘kopen’. In verband met een naderende deadline en een te grote resterende product backlog, werd gezocht naar manieren om meer voortgang te kunnen maken. Tijdelijk uitbreiden van het team met een extra developer werd serieus overwogen. Het bestaande development team, bestaande uit 4 personen, was goed voor een velocity van 40 story points per sprint. Het toevoegen van 1 extra developer zou dan een velocity van 50 story points per sprint moeten opleveren. De gedachte hierachter is begrijpelijk, maar de praktijk laat iets anders zien.
Tijdelijk een nieuw lid aan het team toevoegen zal niet direct resulteren in een hogere productiviteit. De kans bestaat zelfs dat het team iets minder zal opleveren dan het daarvoor deed. Het moet immers wennen aan de nieuwe samenstelling en moet leren hierin weer de optimale samenwerking te vinden. Dit is dan ook niet het doel van het gebruik van de velocity van een team.

Het meten van velocity is optioneel in Scrum. Dat wil zeggen dat de Scrum guide hier niets over vermeldt. Het bijhouden van de velocity is niet verplicht en ik heb situaties meegemaakt waarbij het vooral een negatieve uitwerking had op de productiviteit van het team. Dit gebeurde met name wanneer mensen buiten het Scrum team, zoals stakeholders en mensen uit het management, de velocity misbruikten. Zo heb ik de velocity gebruikt zien worden als belangrijke succes-indicator van een team. Het vergroten van de velocity werd een doel op zich. Want hoe hoger het aantal story points van de afgeronde stories aan het einde van de sprint, hoe meer functionaliteit er werd geproduceerd, was de gedachte. Het gevolg was dat het development-team de user stories hoger ging inschatten om zo makkelijker aan een hogere velocity te komen. Dit leidde vervolgens weer tot een discussie met de product owner; “kost zoiets kleins, zoveel geld?”. Een dergelijke situatie is strijdig met enkele belangrijke kernwaarden van het Scrum framework: transparantie en vertrouwen. Een beoordeling van de daadwerkelijke waarde van het opgeleverde increment voor de organisatie was hierbij meer op zijn plaats. Het vergroten van de velocity zou nooit een doel op zich moeten zijn. Een goed functionerend team kan over een langere tijd een relatief stabiele velocity hebben, maar een geleidelijke toename van de velocity staat niet per definitie garant voor een succesvol team. En een sprint met een lagere velocity dan de vorige kan nog steeds een hele succesvolle sprint zijn geweest waarbij er veel waarde is toegevoegd voor de organisatie.

Een andere (negatieve) ervaring met het meten van velocity heb ik opgedaan in een situatie waarbij meerdere teams ten opzichte van elkaar werden beoordeeld op het aantal stories points van de afgeronde stories per sprint. Het team dat het meeste aantal story points wist te behalen, werd beschouwd als het meest succesvol. De waarde van een story point is echter relatief. Elk team heeft de vrijheid om de waarde van een story point zelf te bepalen op basis wat voor hen het beste werkt. Het vergelijken van story points waarbij de toegekende waarde ervan niet voor alle teams gelijk is, is dan ook een oneerlijke en niet relevante vergelijking.

Dit geldt ook voor het vergelijken van de prestaties van de individuen binnen een team. Het teamlid dat verantwoordelijk is voor de afronding van de stories met het meeste aantal story points, is niet per definitie het meest waardevolle teamlid. Het gehele team is gezamenlijk verantwoordelijk voor het behalen van het gestelde doel voor de sprint. De verschillende karakters, werkniveaus en disciplines van de teamleden kunnen belangrijke factoren zijn om het team als geheel goed te laten functioneren. Een samengesteld team met de ‘best presenterende’ individuen presteert als team wellicht veel minder goed.

Kortom, het bijhouden van de velocity is een goed idee, maar misbruik het niet!