Planning poker

Belangrijk bij het opleveren van goede oplossingen die effectief zijn gerealiseerd is dat je goed weet wat er verwacht wordt en hoe de toekomst er uit gaat zien. Dit kan je nooit 100% weten maar het is ook zeker geen koffiedik kijken. Je kan dit goed leren inschatten. Met het toepassen van middelen die in de wereld van scrum en agile al lang zijn bewezen zorg je ervoor dat je het meeste haalt uit de beschikbare tijd en middelen.

Je zal merken dat sommige user stories veel meer tijd kosten om af te maken dan anderen. Daar moet je rekening mee houden. Ook komen niet alle user stories af aan het eind van een sprint. Iemand kan ziek worden, het uitzoeken van een onderwerp kan langer duren dan verwacht, of soms helpt een docent of studentassistent en kom je er veel sneller uit dan verwacht. Met de burn down chart kan je achteraf te analyseren hoe het ging en wat je kan doen om het beter te plannen.

Het doel is om aan het eind van een sprint zo veel mogelijk van de user stories af te hebben die in het sprintdoel zitten. Daarvoor moet je eerst weten welke user stories meer en welke minder tijd gaan kosten. Dit doe je door als groep te schatten welke de meer tijdrovende user stories zijn en welke minder tijdrovend. Je kan niet zeggen “Deze kost 8 uur tijd” omdat je dat pas achteraf kan weten. Daarom werken we met story points; 1 is het minst, een simpel opzoekwerkje bij voorbeeld, 2 is al iets meer, dan komt 3, 5, dan 8. 8 kan staan voor dagen werk. Je ziet dus dat complexer werk minder nauwkeurig is in te schatten.

Planningpokersessie

Dit inschatten doe je als team tijdens een ‘Planning poker’ sessie. Elk teamlid kiest een getal (b.v. op een kaartje) en iedereen laat tegelijk zien wat zij hebben geschat. Komt er niet bij iedereen hetzelfde getal uit, dan ga je overleggen waar dit verschil vandaan komt totdat de groep het erover eens is welk getal bij deze user story past. In Gitlab zet je dit in het user story erbij via het menu aan de rechterkant bij “Weight”.

Werk inschatten

Elke user story heeft wel verschillende soorten werk; je moet iets bouwen maar dat moet ook worden ontworpen, gedocumenteerd en getest. Ook willen we dat een teamgenoot het werk nakijkt zodat eventuele fouten worden gespot maar ook om er samen van te leren. Dus het kleinste stukje functionaliteit is nog steeds niet in een uurtje te bouwen omdat je nog tijd moet besteden aan deze criteria. Die leg je vast in de Definition of Done (DoD). Het team bepaalt dit samen zodat elk teamlid weet wat verwacht wordt als iemand een user story oppakt.

Sprintplanning

Je kan nu starten met het toewijzen van een eerste groep user stories aan de eerste sprint. Je kan nog niet echt weten hoeveel story points er in één sprint kunnen worden weggewerkt door je team. Dat hangt af van het aantal ontwikkelaars, hun kennis, of er iemand ziek is, en andere omstandigheden. Na veel sprints kan elk team wel behoorlijk goed inschatten hoeveel punten er in de komende sprint passen, ook rekening houdend met vakantie bij voorbeeld. Je gaat dit zelf ervaren door het in sprint 1 te proberen, dan voor sprint 2 te evalueren en nog eens te proberen en zo weer voor sprint 3.

Het toewijzen doe je door de gekozen user stories te koppelen aan een “Milestone” (rechts in het menu). Voor elke sprint is een milestone. Zo kan je achteraf zien hoeveel user stories in elke milestone zaten. Maar je kan er ook mee meten en beter mee leren schatten.

User stories sluiten

Als het user story eenmaal af is, dan zet je het op “Closed”. Daarmee geef je aan Gitlab aan dat het af is. Kijk je op de “burn down chart” (via Plan –> Milestones –> kies Sprint 1) dan zie je ook dat de totale hoeveelheid werk nu naar beneden gaat. Het liefst wil je dat het ongeveer op nul uitkomst als de sprint voorbij is.