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. Dit doe je aan het einde van de sprint.
Gemeengoed binnen Scrum
Het meten van velocity is een gemeengoed binnen Scrum. In bijna alle teams waarmee ik tot nu toe heb samengewerkt, is het ingezet. In veel gevallen ben ik er voorstander van. Het is een geschikt hulpmiddel voor het development team om in te schatten hoeveel werk ze verrichten gedurende een sprint. Met deze informatie kunnen voorspellingen worden gedaan over wanneer een ‘done increment’ opgeleverd en in gebruik kan worden genomen.
In de praktijk
Ik heb een manager meegemaakt die met een simpele rekensom hoopte velocity bij te ‘kopen’. In verband met een naderende deadline en een te grote resterende product backlog, zochten ze naar manieren om meer voortgang te maken. 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 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.
Bijhouden is optioneel
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.
Velocity werd gebruikt 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 het team produceerde, 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.
Waarde is relatief
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, beschouwden ze 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.
Misbruik het niet
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!
