samen
werken
Sprint Planning Checklist
Sprint Planning stappenplan uitgelegd
De Sprint Planning-checklist is opgebouwd uit de onderdelen: doel, frequentie, aanwezigen, voorbereiding, activiteiten tijdens de meeting, en het resultaat van de meeting. De checklist spreekt eigenlijk voor zich en zal in deze alinea niet uitvoeriger worden beschreven.
Hoe pas ik de checklist toe?
De checklist pas je over het algemeen op twee manieren toe. Allereerst gebruik je de lijst als Scrum Master om ervoor te zorgen dat iedereen de taken en verantwoordelijkheden uitvoert die bij zijn of haar rol horen. Zeker beginnende Scrum Masters hebben hieraan veel houvast.
Daarnaast zijn er teams die deze checklist uitgeprint in de Scrumruimte hebben hangen. Zo is het hele team op de hoogte van wat er voor een goede Sprint Planning voorbereid moet worden, hoe de meeting hoort te verlopen, en wat het resultaat van de meeting moet zijn.
De Sprint Planning is misschien wel de meest uitdagende meeting voor Scrumteams. Voor een goedlopende Sprint Planning moet namelijk iedereen zijn rol pakken. Een goede Sprint Planning is dus een echte teamprestatie. Onderstaand overzicht geeft de veelvoorkomende valkuilen voor Scrumteams in een Sprint Planning weer.
- Niet iedereen is aanwezig: zeker bij beginnende Scrumteams kan het uitdagend zijn om iedereen bij elkaar te krijgen, en dat terwijl het team in de Sprint Planning de werkzaamheden voor de komende Sprint bepaalt en uitwerkt. Het is dé kans om vragen te stellen aan de Product Owner over User Stories. Afwezigen lopen deze kans mis en hebben meestal een onvolledig begrip van wat het team oplevert in de Sprint. In de Sprint Planning werkt het Development Team de User Stories uit in kleinere taken. Een afwezig teamlid kan net over de expertise beschikken die nodig is voor deze uitwerking, waardoor het hele team vastloopt. Afwezigheid tijdens Scrum meetings is een van de allergrootste zonden, maar komt helaas veel voor.
- User Stories zijn niet écht ready: voor de meeste Product Owners is het makkelijk om globaal aan te geven wat het Development Team moet opleveren. De uitdaging zit hem echter in het goed uitwerken van een User Story. Denk hierbij bijvoorbeeld aan heldere acceptatiecriteria. Om ervoor te zorgen dat dit goed loopt, stellen veel Scrumteams een ‘Definition of Done’ op. Hierin staat waaraan een User Story moet voldoen voordat het Development Team het werk oppakt.
- Meer werk selecteren dan realistisch is: het is menseigen om de hoeveelheid werk dat gepaard gaat met complexe taken te onderschatten. Onze natuurlijke neiging is daarom om meer User Stories te selecteren en op de Sprint Backlog te plaatsen dan we aankunnen. Als Scrum Master kun je het team hiervoor waarschuwen, maar nog effectiever is om het team een keer de mist in te laten gaan. Gebruik de velocity of ‘snelheid’ van het Scrumteam om in de Sprint Planning te bepalen wat een realistische werkbelasting is. Liever wat minder werk selecteren dat op tijd en goed afkomt dan te veel selecteren en aan het einde van de Sprint niets afhebben.
- De Product Owner voert de druk op: als aanspreekpunt van alle stakeholders heeft de Product Owner een belangrijke bufferfunctie. De Product Owner moet ervoor zorgen dat het team gefocust kan werken aan de taken op de Sprint Backlog en stakeholders weghouden bij het Development Team. Dit gebeurt echter niet altijd. Als stakeholders de druk op de Product Owner opvoeren, hebben sommige Product Owners de neiging om die druk aan het Development Team door te geven. Indien dit gebeurt, zal de Product Owner tijdens de Sprint Planning bevelen dat het team meer werk in de Sprint Backlog op moet nemen. De Scrum Master moet hiervoor waken en als dit toch gebeurt de Product Owner hierop aanspreken.
- Alleen individueel werk inplannen in de Sprint: Scrum gaat over samenwerken en met elkaar meer bereiken dan ieder teamlid individueel kan. Toch hebben Scrumteams dikwijls de neiging om User Stories zo veel mogelijk te verdelen, zodat er minimale samenwerking nodig is. Dit zal uiteindelijk niet ten goede komen aan de kwaliteit.
- Ongelijke verdeling van werk: elke organisatie heeft bepaalde onmisbare medewerkers met uitzonderlijke expertise. Het kan ertoe leiden dat iemand met bijzonder veel expertise veel werk op zich neemt; degene met de meeste expertise kan het immers het best. Als je op de korte termijn denkt, is dit juist, maar op de lange termijn houd je de afhankelijkheid van deze persoon in stand. Veel beter is het dus om te werken aan hoe deze persoon expertise kan overbrengen op de andere teamleden. De totale productiviteit van een team neemt toe als meer mensen het werk van de meest schaarse resource kunnen overnemen. Dit is een goed argument voor T-shaped medewerkers.
- Langer doorgaan dan de timebox: bij Scrum staat de duur van een meeting vast, en dat is niet voor niets. De Sprint Planning is de meeting die het vaakst uitloopt. Dat kan verschillende oorzaken hebben. Meestal zijn User Stories niet ver genoeg uitgewerkt, waardoor het Development Team veel vragen stelt over wat ze moeten opleveren. Ook kan er onenigheid ontstaan over prioriteiten, waardoor de meeting uitloopt. Het is dan zaak dat het Development Team de prioritering van de Product Owner accepteert.
Is je interesse gewekt in Scrum? Wil je hier meer over leren? Volg dan één van onze Scrum Trainingen.
Ook interessant:
Volg ons op LinkedIn (we delen onze blogs met je)
