Velocity-gebaseerde Sprint Planning

Er zijn twee fundamentele manieren om een Sprint te plannen:

1. Velocity-georiënteerde Sprint Planning (gericht op de gemiddelde werkcapaciteit van een team), en

2. Commitment-georiënteerde Sprint Planning (gericht op wat een team denkt in een Sprint te kunnen realiseren).

Velocity-gebaseerde Sprint Planning

Hier gaat het om velocity-gebaseerde Sprint Planning. De hoeveelheid werk die voor de volgende Sprint wordt gepland, zou ongeveer overeen moeten komen met die van de voorgaande Sprints. Dat veronderstelt natuurlijk dat de teamgrootte ongeveer gelijk blijft, dat er in de Sprints vergelijkbare taken worden uitgevoerd, dat de Sprints ongeveer even lang zijn, enzovoort. Afwijkingen van deze voorwaarden zijn gelukkig makkelijk te herkennen. Als een Sprint bijvoorbeeld door een feestdag maar negen in plaats van tien dagen duurt, weet het team dat natuurlijk al van tevoren.

De afzonderlijke stappen bij velocity-georiënteerde Sprint Planning:

• Achterhalen wat de gemiddelde Velocity van het team was bij eerdere Sprints.

• Op basis van deze Velocity het juiste aantal Product Backlog Items selecteren.

• De afzonderlijke taken van de User Stories in kaart brengen en overwegen of het de juiste hoeveelheid werk zou kunnen zijn.

• Inschatten of deze taken net zoveel werk vereisen als die in eerdere Sprints.

Laten we deze stappen eens nader bekijken.

Stap 1: De gemiddelde velocity van een team bepalen

De eerste stap bij velocity-gebaseerde Sprint Planning is het vaststellen van de gemiddelde velocity van een team. Sommige agile teams richten zich alleen op de velocity van hun laatste Sprint. Veel teams geloven dat dit de beste indicator is voor wat er in de volgende Sprint bereikt kan worden. Dat is natuurlijk niet verkeerd. Het kan echter nuttig zijn om nog iets verder terug te kijken (als die gegevens beschikbaar zijn).

Daarvoor bekijk je de velocity van de laatste drie tot acht Sprints. De ervaring leert dat je zo toekomstige Sprints redelijk goed kunt voorspellen. Je moet het natuurlijk niet overdrijven en het gemiddelde van de afgelopen tien jaar berekenen. Dat zou immers niets zeggen over de huidige velocity van een team. Als de gegevens van eerdere Sprints echter beschikbaar zijn, is het aan te raden om niet alleen naar die ene laatste Sprint terug te kijken.

Stap 2: Product Backlog Items selecteren

Op basis van de zojuist bepaalde gemiddelde velocity kunnen de teamleden vervolgens de items voor de volgende Sprint selecteren. Samen zouden deze – op zijn minst bij benadering – overeen moeten komen met de gemiddelde velocity.
Op dit punt is velocity-gebaseerde Sprint Planning in principe afgerond en kan het binnen enkele seconden klaar zijn – zodra het team de Product Backlog Items op basis van zijn gemiddelde velocity heeft geselecteerd, is het klaar.

Stap 3: Tasks bepalen (optioneel)

Vaak is deze korte tijd voor een Sprint Planning echter niet echt voldoende. Daarom kunnen teams een derde stap aan hun planning toevoegen, waarbij de uit te voeren tasks worden bepaald.
Hiervoor bespreken de teamleden elk afzonderlijk Product Backlog Item dat voor de Sprint is geselecteerd. Ze proberen vast te stellen welke werkstappen nodig zijn om de items af te ronden. Natuurlijk kan niet aan alles gedacht worden, maar je moet proberen om zoveel mogelijk mee te nemen.

Daarna bekijkt het team of de geselecteerde items en de bijbehorende tasks de Sprint zullen vullen. Op basis daarvan kunnen er dan nog items aan de Sprint worden toegevoegd of verwijderd.

Sommige teams beëindigen hun Sprint Planning nu, andere voeren nog een laatste stap uit:

Stap 4: De tasks inschatten (optioneel)

Sommige teams schatten tot slot nog in hoeveel uur ze waarschijnlijk nodig hebben voor de geselecteerde tasks. Hieraan kunnen ze zien of ze de juiste hoeveelheid werk hebben ingepland.

Deze tekst is afkomstig uit de blog van Mike Cohn en door ons naar het Nederlands vertaald.