Commitment-georiënteerde Sprint Planning

Er zijn twee fundamentele manieren om een Sprint te plannen:

1) Velocity-georiënteerde Sprint Planning
(gericht op de gemiddelde werklast van een team), en
2) Commitment-georiënteerde Sprint Planning
(gericht op wat een team denkt te kunnen bereiken in een Sprint)

Velocity-georiënteerde Sprint Planning heb ik al toegelicht, dus richten we ons hier op de Commitment-georiënteerde Sprint Planning:

Commitment-georiënteerde Sprint Planning Meetings betrekken de Product Owner, de ScrumMaster en het volledige ontwikkelteam. De Product Owner geeft een overzicht van de Product Backlog Items met de hoogste prioriteit en licht deze vervolgens toe aan het team.

Een item selecteren

Vervolgens kiezen de teamleden een item voor de volgende Sprint. In de meeste gevallen komt dit overeen met het item waaraan de Product Owner de hoogste prioriteit heeft gegeven. Het kan echter ook voorkomen dat het item van de Product Owner nog te veel onopgeloste punten bevat.

Idealiter zou het team toch in staat moeten zijn om dit item in de Sprint op te nemen en de openstaande vragen vroeg genoeg te beantwoorden om het item alsnog af te ronden. Als er echter te veel, te zware of te tijdrovende punten zijn die opgelost moeten worden, dan kan het door de Product Owner geselecteerde item beter even worden overgeslagen.

Taken en uren

Nadat een item is geselecteerd, bespreken de teamleden het bijbehorende werk en bepalen ze de tasks (taken) die nodig zijn om het Product Backlog Item op te kunnen leveren. Tijdens of direct na deze bespreking schat het team in hoeveel tijd (uren) ze ongeveer nodig hebben voor de afzonderlijke tasks.

Verwacht echter niet dat het team voor elke task een inschatting geeft. Dat is niet alleen onmogelijk, maar ook onnodig.

De teamleden hoeven slechts zoveel tasks in te schatten dat ze het gevoel krijgen alles voldoende te hebben doordacht. Want dát is het eigenlijke doel van zo'n meeting. Tasks en uren vastleggen is bijzaak.

De vraag over commitments

Zodra de teamleden de taken hebben vastgesteld en globaal kunnen inschatten hoe lang ze voor bepaalde Backlog Items nodig hebben, moeten ze zichzelf de vraag stellen: "Kunnen we hier een commitment voor afgeven?"

Ik vind het belangrijk dat het team zichzelf deze vraag stelt en niet door de Scrum Master wordt gevraagd: "Kunnen jullie hier een commitment voor afgeven?" Want zo verplichten ze zich tegenover elkaar, in plaats van tegenover de Scrum Master.

Ik weet niet hoe het bij jou was, maar mijn eerste jaren in het werkende leven (in de tijd vóór Scrum) werden gekenmerkt door onhaalbare commitments tegenover leidinggevenden, die weliswaar vroegen "Kun je dat halen?", maar eigenlijk bedoelden "Zorg dat je dat haalt!"

Ook al wordt de Scrum Master als "Master" aangeduid, hij is geen leidinggevende van het team en zou dat gevoel ook niet moeten wekken. Het is beter om niet als baas gezien te worden die op de nakoming van alle commitments staat.

In plaats daarvan moet een team ertoe gebracht worden om zichzelf te vragen: "Kunnen we een commitment afgeven?" Want een commitment is veel sterker wanneer het team zich tegenover zichzelf ergens toe verplicht.

Bovendien is het duidelijk dat er op de vraag van het team "Kunnen we een commitment afgeven?" slechts twee mogelijke antwoorden zijn, namelijk "Ja, dat kunnen we" of "Nee, dat kunnen we niet." Als daarentegen de Scrum Master vraagt "Kunnen jullie een commitment afgeven?", zullen sommige teamleden met "wij" antwoorden en anderen met "ik".

Scrum vereist een commitment van het hele team: "Als je hulp nodig hebt, zal ik je helpen en ik weet dat jij hetzelfde voor mij zou doen." en niet "Dit zijn mijn taken en dat zijn de jouwe."

Het proces bij verdere Stories herhalen

Wanneer het team het erover eens is dat ze voor een bepaald Product Backlog Item geen commitment kunnen afgeven, kiezen ze een ander item en herhalen ze het proces – taken, uren, commitment – totdat iemand zegt dat hij of zij voor het gekozen item geen commitment kan afgeven.

Als dat het geval is, bespreken de teamleden de situatie en kijken ze of iemand anders misschien kan helpen. Misschien kan een databasebeheerder met basiskennis van JavaScript een overbelaste JavaScript-ontwikkelaar ondersteunen.

Mocht dat niet het geval zijn, dan kan de story terug naar de backlog worden geschoven en kan er een kleiner of eenvoudiger item worden gekozen waarvoor iedereen wel een commitment kan afgeven.

Hoe zit het met Story Points en Velocity?

Misschien is het je al opgevallen dat in dit proces tot nu toe noch Story Points noch Velocity een rol speelden. Ik raad nog steeds aan om Product Backlog Items met behulp van Story Points in te schatten. Maar Story Points en Velocity spelen tot dit punt geen echte rol bij commitment-georiënteerde Sprint Planning. Ze spelen echter wel een belangrijke rol in de laatste fase van een Sprint Planning Meeting.

Plausibiliteitstoets van de Commitments

Zodra het team de beschikbare tijd in een Sprint heeft gevuld, kan de Scrum Master bekijken hoeveel Story Points de afzonderlijke items eerder hebben gekregen. Het resultaat deelt hij vervolgens met het team. Het team kan dit getal dan vergelijken met zijn gemiddelde of huidige Velocity .

Laten we aannemen dat een team met een gemiddelde Velocity van 20 zo'n Sprint Planning Meeting houdt en items selecteert die in totaal op 19 Story Points uitkomen. Ze hebben deze items geselecteerd zonder te weten hoeveel Story Points er eerder aan waren toegekend.

Als de Scrum Master hen nu vertelt dat ze zojuist items met in totaal 19 Points hebben geselecteerd en dat hun gemiddelde Velocity gelijk of zeer vergelijkbaar is, kunnen de teamleden ervan uitgaan dat ze de juiste hoeveelheid werk voor de Sprint hebben gepland.

Als er echter slechts items met in totaal 11 Story Points zijn geselecteerd, moeten ze zich afvragen waarom ze het werk nu als zoveel moeilijker hebben ingeschat.

Dat kan bijvoorbeeld komen doordat ze tijdens de Sprint Planning werk hebben geïdentificeerd dat ze eerder niet hadden meegenomen. Of ze stellen simpelweg vast dat een Story in werkelijkheid ingewikkelder is dan gedacht.

In elk geval weet het team of het een passende hoeveelheid werk heeft gekozen of dat er misschien nog meer ingepland kan worden.

Aan de andere kant zullen de teamleden zich afvragen wat ze niet hebben meegenomen als ze items met in totaal 30 Points hebben geselecteerd – dus 10 meer dan hun gemiddelde. De vraag zou dan kunnen zijn: "Waarom lijkt dit werk na de Sprint Planning zoveel eenvoudiger dan daarvoor?"

Velocity en Story Points spelen dus geen rol gedurende het grootste deel van een commitment-georiënteerd Sprint Planning Meeting. Ze zijn echter onmisbaar als het erom gaat de planning te controleren en te bevestigen.

Een commitment is geen garantie

Het is belangrijk om een commitment nooit als garantie te zien. Zoals Clint Eastwood al in een van zijn films zei: "Als je een garantie wilt, koop dan een broodrooster!"

Het commitment van een team betekent dat iedereen zijn best doet. Als ze hun commitments in 80 procent van de gevallen kunnen nakomen, is dat een goed gemiddelde. Het betekent ook dat ze de zaak serieus nemen en de tijd optimaal moeten benutten. Dat schept vertrouwen in het team en in wat het zegt te kunnen leveren.

Het zou echter niet het doel moeten zijn om altijd alles voor 100 procent af te krijgen. Een team dat gedwongen wordt om altijd alles af te ronden, zal dat weliswaar kunnen – maar alleen door zijn commitments lager in te zetten.

Ik heb deze aanpak "commitment-georiënteerde Sprint Planning" genoemd. Hij wordt echter ook als "Capaciteitsgebaseerde Planning" aangeduid. Die term bevalt me steeds beter, omdat een commitment simpelweg te gemakkelijk als garantie begrepen kan worden.

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