Wat gebeurt er in een Sprint en wanneer?
Een succesvolle implementatie van Scrum omvat een aantal belangrijke ceremonies. Denk aan Sprint Planning, Sprint Review, Daily Scrum, Sprint Retrospective en meer.
Vaak is er onduidelijkheid over wie aan welke Scrum ceremonies zou moeten deelnemen, wanneer ze plaatsvinden, hoe lang ze zouden moeten duren, wat het doel van elke ceremonie is, enzovoort.
In dit artikel proberen we die onduidelijkheden weg te nemen:
De Sprint Planning
Wanneer de Sprint begint, wordt ook de Sprint Planning uitgevoerd. Het markeert dus officieel de start van de Sprint.
Het volledige Scrum Team neemt deel aan de Sprint Planning ; dat wil zeggen zowel het Development Team als de Scrum Master en de Product Owner. In zeldzame gevallen kunnen ook andere personen aan dit event deelnemen, als de Product Owner en het Development Team dit passend vinden. Als er bijvoorbeeld in de komende Sprint functionaliteit ontwikkeld moet worden die het best door een vakexpert uitgelegd kan worden (die niet tegelijkertijd de Product Owner is), kan het handig zijn als deze persoon bij de Planning aanwezig is. In de meeste gevallen is het echter het meest zinvol om deze discussies buiten de eigenlijke Planning Meeting te voeren.
De duur van de Sprint Planning is proportioneel aan de lengte van de Sprint. Bij een Sprint van vier weken mag de Planning niet langer dan acht uur duren; bij een Sprint van één week niet langer dan twee uur – dus maximaal twee uur per Sprintweek.
Deze beperking tot een maximale duur van een meeting noemen we ook wel Time Boxing. Ik raad teams aan om bij voorkeur in ongeveer de helft van de maximaal toegestane Time Box klaar te zijn met de Sprint Planning.
Als input voor de Sprint Planning brengt de Scrum Master informatie mee over de gemiddelde en actuele Velocity (werksnelheid). De Product Owner brengt het Product Backlog mee, of in ieder geval de Backlog Items met de hoogste prioriteit. Bij sommige teams stelt de Product Owner tijdens de Planning ook al een voorlopig Sprint-doel op, dat vervolgens samen met het team tijdens de Planning kan worden bijgewerkt.
Het resultaat van de Sprint Planning is een beter geïnformeerd team dat beter voorbereid is op het werk dat eraan komt. Verdere resultaten van de Planning zijn het Sprint Backlog en een gezamenlijk opgesteld Sprint-doel.
Daily Scrum / Daily Standup
De Daily Scrum – ook wel Daily Standup genoemd – is een korte ceremonie die dagelijks plaatsvindt en waarbij teamleden hun werk op elkaar afstemmen. Met Daily Scrums zorg je ervoor dat de juiste mensen op het juiste moment aan de juiste dingen werken.
Elke dag beantwoordt elk teamlid de volgende drie vragen:
Wat heb ik gisteren gedaan om het Sprint-doel te bereiken?
Wat ga ik vandaag doen om het Sprint-doel te bereiken?
Zijn er obstakels/problemen die me tegenhouden, en zo ja, welke?
Deze vragen kunnen op heel verschillende manieren geformuleerd worden. Sommige teams beschrijven bijvoorbeeld liever wat ze bereikt hebben, in plaats van wat ze gedaan hebben.
Deelnemers zouden de ScrumMaster, het ontwikkelteam, en naar mijn mening ook de Product Owner moeten zijn.
In de Scrum Community zijn er nogal wat discussies over de vraag of de Product Owner nu wel of niet aan de Daily Scrum zou moeten deelnemen. De Product Owner toestaan om niet deel te nemen aan de Daily Standup, kan hem te veel van het team afzonderen. Een "wij-tegen-zij"-gevoel bestaat al in te veel organisaties. Ik kan me niet voorstellen waarom een Scrum Team of hun Product Owner deze negatieve houding nog verder zou willen versterken.
De Daily Scrums zijn beperkt tot een duur van maximaal 15 minuten. Het doel van de Daily Scrum is een korte synchronisatie van het team. Anders dan bij Sprint Planning raad ik hier niet aan om al in de helft van de voorziene tijd klaar te zijn. Voor de meeste teams zijn 5-7 minuten simpelweg niet genoeg om echte problemen te bespreken of te begrijpen welk werk er is afgerond. Als de Daily Scrums te veel worden ingekort, worden ze al snel routine met uitspraken als "Gisteren heb ik XY gedaan. Vandaag doe ik dit en dat. Ik heb geen impediments."
Er zijn geen formele resultaten van de Daily Scrums, behalve de verbeterde coördinatie van het werk in het ontwikkelteam.
Sprint Review
De Sprint Review vindt plaats op de laatste dag van de Sprint. Product Owner, ScrumMaster en het ontwikkelteam moeten hierbij aanwezig zijn, evenals de betreffende Stakeholders. Welke Stakeholders erbij moeten zijn, verschilt per Sprint en hangt af van wat er in de Sprint is opgeleverd.
De Sprint Review heeft een Time Box van maximaal vier uur voor een Sprint van vier weken. Voor kortere Sprints is de Time Box evenredig korter, bijvoorbeeld één uur voor een Sprint van één week.
In de Sprint Review moeten alle Product Backlog Items worden getoond die voldoen aan de Definition of Done. Dit betekent dat er geen werk wordt getoond waar nog aan gewerkt wordt en dat dus nog niet is afgerond. Soms kan het natuurlijk wel zinvol zijn om een uitzondering op deze regel te maken.
De demonstratie van afgeronde functionaliteit is de centrale activiteit van een typische Sprint Review Meeting. De meeste teams nemen echter ook de tijd om de voortgang en eventuele problemen te bespreken.
Het doel van de Review Meeting is om feedback te verzamelen op wat er tijdens de Sprint is ontwikkeld. De Product Owner neemt alle feedback in ontvangst en kan op basis van deze feedback, indien nodig, de Product Backlog aanpassen. Het resultaat van een Sprint Review is dus een bijgewerkte Product Backlog.
Sprint Retrospective
In de Sprint Retrospective krijgen de teamleden de gelegenheid om na te denken over hoe ze hun manier van werken kunnen verbeteren. Dat kan bijvoorbeeld betekenen dat ze de manier waarop ze Scrum toepassen willen veranderen en dan bijvoorbeeld de sprintlengte aanpassen. De Retrospective kan ook algemene aspecten van de samenwerking behandelen, zoals 's ochtends geen meetings meer inplannen of afspreken welke onderwerpen je via Slack kunt bespreken en welke je beter in een persoonlijk gesprek kunt oplossen.
Aan de Sprint Retrospective moet het volledige team deelnemen – dat wil zeggen het Development Team, de ScrumMaster en de Product Owner. Alles anders zou alleen maar tot een splitsing in het team leiden. Een goed agile team moet elk gedrag vermijden dat leidt tot een "wij-tegen-zij"-mindset.
Naast de wil om te verbeteren is er voor de Sprint Retrospective geen verdere input nodig. Het resultaat van de Retrospective moet een lijst zijn met veranderingen of verbetervoorstellen die het team wil doorvoeren.
De timebox voor een Retrospective is maximaal 3 uur. Af en toe kan het iets langer duren, maar in de meeste gevallen zijn teams er binnen een uur mee klaar.
Product Backlog Refinement
De Product Backlog Refinement zorgt ervoor dat de items bovenaan de Backlog klaar zijn voor de volgende Sprint. Dat kan betekenen dat je details toevoegt aan bestaande items, inschattingen maakt, bepaalde items verwijdert, prioriteiten herschikt, Backlog Items opsplitst in kleinere items of nieuwe items aanmaakt.
Hoewel het verfijnen van de Backlog op zich noodzakelijk is, betekent dat niet dat een team dit als officiële ceremonie moet doen of dat het elke Sprint moet plaatsvinden. De meeste teams houden echter regelmatig Backlog Refinement Meetings, meestal één keer per Sprint of per week.
Een goede richtlijn is dat een team niet meer dan 10% van de totaal beschikbare tijd aan Backlog Refinement besteedt – zowel in het meeting zelf als in de latere discussies die daaruit voortkomen.
Bij de meeste teams nemen zowel alle leden van het Development Team als de Product Owner en de ScrumMaster deel aan de meetings. Tenzij een team de Product Backlog Items inschat tijdens de Refinement Meetings, denk ik dat ongeveer de helft tot twee derde van de ontwikkelcapaciteit voldoende is en dat het meeting zo voor het team zo kort mogelijk gehouden kan worden.
Het enige dat je bij de Refinement moet meenemen, zijn de bovenste items van de Product Backlog. Resultaten van de Refinement zijn kleinere Product Backlog Items die beter geschikt zijn voor de volgende Sprint, en een beter begrip van bepaalde Product Backlog Items.
Beoordeling van de Backlog
Zoals hierboven al genoemd, schatten veel teams hun Product Backlog Items al in tijdens het Refinement Meeting. Dat is de ideale situatie en indien mogelijk neemt het volledige ontwikkelteam deel aan het Backlog Refinement.
Als slechts een deel van het team deelneemt aan het Refinement, komen de teamleden één keer per Sprint samen om al het nieuwe werk in te schatten waarvoor de Product Owner een inschatting nodig heeft.
Bij de meeste teams zouden deze inschattingsmeetings heel kort moeten zijn. Teams zouden namelijk niet te veel nieuwe Product Backlog Items moeten aanmaken, en ook geen stortvloed aan nieuwe items van buitenaf moeten ontvangen. Het werk dat ingeschat moet worden, zou ofwel zeer belangrijk moeten zijn, of het gaat om nieuwe of bestaande items die zijn opgesplitst om beter in de komende Sprint te passen.
Ik voer het Product Backlog Estimating graag direct na een Daily Scrum uit, een paar dagen voor het einde van de Sprint. Dat is laat genoeg zodat de meeste nieuwe items al geïdentificeerd zijn, en vroeg genoeg voor de Product Owner om de prioritering op basis van de nieuwe informatie uit de inschattingen aan te passen.
Ik raad niet aan om items tijdens de Sprint Planning in te schatten. Dan is het namelijk te laat voor de Product Owner om de prioritering op basis van de inschattingen aan te passen. Het zorgt er bovendien voor dat teamleden meer tijd besteden aan de inschattingen dan nodig is. Dus: schat Product Backlog Items niet in tijdens de Sprint Planning.
Prioritering
Voordat een nieuwe Sprint begint, zorgt de Product Owner ervoor dat alle items bovenaan de Product Backlog geprioriteerd zijn. Volgens het Oxford American Dictionary betekent prioriteren: „Taken, problemen etc. op volgorde van belangrijkheid zetten, zodat je de belangrijkste als eerste kunt aanpakken."
Dat betekent dat het niet voldoende is om te zeggen: „Ze zijn allemaal nodig." Of zoals een Product Owner me ooit vertelde: „Het zijn niet voor niets requirements; ze zijn vereist."
In de meeste gevallen zal er geen officiële ceremonie voor de prioritering zijn. Het is eerder iets wat de Product Owner zelfstandig doet, na gesprekken met de stakeholders om hun behoeften en wensen te verduidelijken.
De prioritering zou zo laat mogelijk in de Sprint moeten plaatsvinden, maar moet in elk geval vóór de volgende Sprint afgerond zijn. Dat kan vaak betekenen dat het op een van de laatste twee dagen van de Sprint wordt gedaan.
De prioritering is normaal gesproken niet bijzonder tijdrovend, omdat de Product Owner doorgaans pas in de loop van de Sprint de fijnafstemming doet op basis van nieuwe inzichten, in plaats van vanaf het begin de hele backlog tot in detail te prioriteren.
De meetings in een Sprint
Zoals je ziet, zijn er een aantal belangrijke ceremonies in Scrum die je zorgvuldig zou moeten uitvoeren. Hopelijk heeft dit artikel je een beter overzicht gegeven en voor meer duidelijkheid gezorgd in het dagelijks werk met je Scrum Team. Als je nog meer wilt leren, zijn onze Scrum Trainings precies wat je zoekt.
Dit artikel is afkomstig uit de blog van Mike Cohn en is door ons naar het Nederlands vertaald.
