Een belangrijk aspect hiervan is de velocity (snelheid): het aantal Story Points Done in één sprint. Kijk wel uit dat je bij het meten van prestaties niet téveel waarde hecht aan dit specifieke getal, want uiteindelijk gaat het om de toegevoegde waarde, en dat is moeilijker te meten.

Gebruik velocity dus niet om de kwaliteit van teamprestaties in uit te drukken. Gebruik het meer als hulpmiddel om te bepalen hoeveel werk er in de volgende sprint(s) kan worden opgepakt en voor berekeningen t.a.v. de roadmap. Deze voorspelling is sterk afhankelijk van de capaciteit, oftewel de beschikbaarheid van teamleden. Zo kunnen we bijvoorbeeld tijdens de zomervakantie, met 50% van het team op vakantie, slechts 50% van het werk doen – niet heel verrassend. Maar er zijn meer factoren die meespelen.

Hoe kunnen we velocity meten?

Het klinkt eenvoudig: neem de velocity van de laatste zes sprints en bereken het gemiddelde…

Helaas is het niet zo simpel, je moet namelijk ook met een aantal andere zaken rekening houden:

• De capaciteit: zijn er meer (of minder) vakantiedagen opgenomen dan gemiddeld?
• Teamgrootte: zijn er nieuwe mensen bijgekomen of juist weggegaan?
• Overflow stories: een slechte sprint waarbij veel voor 80% ontwikkelde stories aan het einde van de meetperiode naar de volgende sprint gingen of een eerste sprint met een zeer hoge velocity omdat het begon met veel voor 80% ontwikkelde stories van een vorige sprint. Dit wordt over een groot aantal sprints gelijkgetrokken, maar over een klein aantal kan het de cijfers scheeftrekken.

Je begint dus met de Full team velocity. Dit is je gemiddelde velocity wanneer je volledige team beschikbaar is voor de sprint. Voor dit rekenvoorbeeld nemen we 80 SP.

Dan moeten we alle variabelen in de berekening opnemen. Is bijvoorbeeld 50% van het team op vakantie? Dan moet je je sprint aanpassen naar 40 SP.

Bij INFO hebben we bijvoorbeeld 30 vakantiedagen per jaar. Als we daar feestdagen en verlof bij optellen, werken we ongeveer op 87% van de Full team velocity, wat resulteert in 70 SP. Ik noem dit de ‘gemiddelde velocity’. Dus als we een project van 350 SP hebben, en de gemiddelde velocity is 70 SP, dan hebben we tussen de vier tot zes sprints nodig, laten we zeggen vijf.

Als je de Full team velocity (prestaties uit het verleden) hebt berekend, heb je waardevolle informatie als input voor de Sprint Planning.

Het berekenen van ‘toekomstige capaciteit’ en het effect op de sprint velocity

Als wiskundefanaat, heb ik dit eerste onderdeel veranderd: samen met andere teamleden hebben we een Excel-sheet gemaakt waarin je de vakanties en verlof tijdens die sprint invoert om meer zicht op de velocity te krijgen. Na deze eerste velocity-berekening, kijkt het team naar impediments en andere factoren die de velocity kunnen beïnvloeden.

Uiteindelijk is het aan het team om de velocity te bepalen, maar de eerste berekening wordt nu gedaan door Excel. De Product Owner kan deze Excel ook gebruiken, om een week voor de Sprint Planning de velocity in te schatten en om een idee te krijgen van welke stories tijdens deze sprint opgepakt kunnen worden. Je kunt deze Velocity Excel downloaden van ons GitHub-account. Vergeet niet het README-tabblad te lezen voor meer informatie.

Overflow stories en het effect op de sprint velocity

In Scrum willen we waarde leveren, en een story die slechts voor 80% is ontwikkeld, levert nog geen waarde op, omdat die nog niet klaar is. Dus wanneer we de velocity van een voltooide sprint berekenen, kijken we alleen naar de stories die klaar zijn.

Dit aantal zegt echter niet genoeg om de velocity voor een volgende sprint vast te stellen. We moeten ook rekening houden met de overflow stories. Maar hoe?

Kijk tijdens de Sprint Planning-ceremonie naar de stories die in de vorige sprint zijn gestart en die nu zijn toegevoegd aan de nieuwe sprint. Vraag dan bij elke story aan het team: hoeveel SP’s zijn er ontwikkeld?

Voorbeeld:
Story 1: 8 SP waarvan 7 SP al ontwikkeld
Story 2: 13 SP waarvan 11 SP al ontwikkeld
Totaal: 18 SP al ontwikkeld

Tel deze 18 SP op bij je geschatte velocity: 18 + 70 = 88 SP en laat je team de laatste check doen bij het vullen van de sprint met ongeveer 60 SP (inclusief die gedeeltelijk ontwikkelde stories). Ik noem deze 60 SP het ‘doel’.

Aangezien ik beide getallen nodig heb en ze van elkaar wil onderscheiden, noem ik de voorspelde velocity van de sprint de ‘velo’ (onafhankelijk van overflow stories) en het getal inclusief de overflow stories het ‘doel’. Als PO vul je je sprint tijdens de Sprint Planning met dit doel voor ogen en als team ben je waarschijnlijk blij om dat doel te bereiken.

Praktische tip: In JIRA – een veelgebruikte tool voor het managen van backlogs/sprints – maakt de PO meestal al een volgende sprint aan, dus ik voeg dit velocity getal toe aan het ‘sprint goal’-veld waardoor het op de JIRA-backlog verschijnt. Vaak voeg ik de velocity van de volgende sprint al een week voor de volgende sprint toe, zodat de PO een idee krijgt van de hoeveelheid werk die hij/zij moet voorbereiden.

Aan het begin van de Sprint Planning, als we het aantal overflow stories weten en het doel hebben berekend, tellen we dit doelgetal ook bij het ‘sprint goal’-veld op.

Impediments, de stories en andere factoren die velocity kunnen beïnvloeden

Tijdens het laatste onderdeel, voegt het team waardevolle kennis toe over impediments, complexiteit en onzekerheid van stories, en andere factoren die de velocity kunnen beïnvloeden (zoals een trainingsdag). Dit leidt tot de uiteindelijke collectie van stories die in de sprint kan worden opgepakt.

Een goed gestructureerde capaciteits- en overflow-berekening is een cruciaal onderdeel van de Sprint Planning en vraagt om tijd en aandacht.

Hopelijk heb je hiermee wat extra kennis opgedaan over hoe je je Sprint Planning en velocity berekeningen kunt verbeteren. Vergeet niet om af en toe je Full team velocity te controleren en bij te stellen.

Laat het me weten als je tips of opmerkingen hebt!