Sprints in scrum en agile: zo werkt het

Sprint in agile en scrum

Werk je een in agile team of met scrum? Dan werk je waarschijnlijk in zogenoemde sprints. In dit artikel leg ik je uit wat een sprint precies is en hoe je het werk in een sprint cyclus zo goed mogelijk kan managen.

Laten we beginnen!

Wat is een sprint?

Een sprint is een kort project binnen het grote scrum project.

Je bepaalt van tevoren welke taken je gaat oppakken, je hebt een duidelijk doel met de sprint en je weet wat je als team gaat opleveren binnen de gezette sprint.

Het gehele project bestaat uit een aantal sprints die nodig zijn om het totale product op te leveren.

Hoelang duren zo'n sprint?

Je bent in principe vrij om zelf te kiezen hoelang sprint cyclus duurt. Soms zal je project sprints van een week hebben, soms van langere duur. Bijvoorbeeld een week of vier. Heel veel langer dan dat moet je in de meeste gevallen niet willen.

Hoe lang je sprint ook duurt, het idee is dat je om en nabij 80-85% van de tijd in de sprint besteed aan het daadwerkelijke werk.

De rest van de tijd gaat op aan planning en de daily scrum meeting.

Voor het plannen van de sprint zou je bij een korte sprint (één week) niet meer dan twee uur kwijt moeten zijn en voor een langere sprint (vier weken) niet meer dan acht uur.

Wie zijn er betrokken bij een sprint?

Tijdens het uitvoeren van de sprint organiseren de leden van het team zichzelf.

Ze bepalen dan best mogelijke manier om het sprint doel te bereiken. Hierin begeleid de Scrum Master het team.

De Scrum Master zorgt ervoor dat belemmeringen in de sprint die vertragen of teamleden blokkeren worden opgelost.

De Product Owner is zijdelings betrokken bij de sprint. Wanneer er vragen zijn of tussentijds feedback moet worden gegeven aan het team, dan doet de Product Owner dit.

Ondanks dat het hele scrum team gezamenlijk verantwoordelijk is voor het project is de Product Owner de enige rol die – als het goed is – het gehele project overziet en de stakeholders kan managen.

Ontstaat er in de sprint de behoefte om de doelen aan te passen of lopen zaken uit Dan kan de Product Owner hier in meedenken en informatie inbrengen om de juiste prioritering te kiezen.

Hoe ziet het proces van een sprint eruit?

Om een sprint goed te kunnen uitvoeren kom je volgende activiteiten tegen.

Het selecteren van de taken

Voor elke sprint kijkt het team naar de product backlog van het hele project. Hieruit worden door het team onder begeleiding van de Product Owner de meest relevante taken voor de sprint geselecteerd.

Deze worden vervolgens meegenomen naar de “sprint backlog”.

Het idee van de product backlog en de sprint backlog is in principe hetzelfde. Alles in een backlog moet worden geprioriteerd en worden uitgevoerd.

Als het goed is het je in je product backlog al een goed beeld van de belangrijkste userstories en bijbehorende efforts bijvoorbeeld door Scrum Poker te spelen en product backlog refinement te doen.

Heb je een subset van taken geselecteerd voor de sprint backlog? Dan kan je de sprint backlog verder organiseren en prioriteren met het team.

In praktisch alle gevallen heb je nu in ieder geval een Kanban bord waarin helemaal links onder “sprint backlog” een reeks aan goed gedefinieerde en geprioriteerde taken staan.

Je kan je sprint op verschillende manieren bijhouden. Bijvoorbeeld met post-IT’s of met scrum software.

Ik raad je aan om je hele scrum project of agile project te managen met projectmanagement software. Hiermee kan je met je team gemakkelijk kan samenwerken waar en wanneer je wil.

Monday is zo’n software tool. Hier kan je praktisch elk onderdeel van een scrum project in volledige samenhang managen.

Heb je nog geen goede tool of loop je tegen beperkingen aan binnen je huidige tool Probeer Monday dan. Het is een freemium tool, maar je kan met de gratis versie al heel veel.

Je kan praktisch alles zelf inrichten op een gebruikersvriendelijke manier.

Mocht je besluiten dat je Monday voor langere tijd wil aanslingeren in jouw team, dan heb je voor een paar euro per gebruiker doorlopende toegang.

Workflow management

Tijdens de sprint is het de verantwoordelijkheid van het team om het werk zo te managen dat aan het einde van de sprint het doel behaald is.

Hiervoor is gezamenlijke inschattingen en afstemming nodig.

Je hebt als het goed is de sprint backlog al geprioriteerd en je weet hoeveel efforts elke taak gaat kosten. Maar, wie gaat de taken oppakken? En doe je dit aan het einde van de sprint of juist bij de start?

Laten we wat verder inzoomen op de opties hier.

Meerdere taken parallel uitvoeren in scrum

Tijdens de start van de sprint bepaalt het team hoeveel items van de backlog tegelijkertijd opgepakt kunnen worden.

Werk je aan veel taken tegelijkertijd? Dan kan dat vertragend werken.

Werk je er maar aan weinig? Dan kan het zijn dat sommige teamleden soms zitten te wachten en niet goed worden ingezet.

Hier moet je een gezonde balans in vinden met het team.

Naar mijn mening gaat dit naar mate je verder als team meer ervaring opgedaan hebt steeds wat beter.

Je kalibreert namelijk langzaam naar een werkbaar optimum voor jouw team. Een bepaalde mate van parallelle werkzaamheden is er altijd is iets goeds.

Het uiteindelijke doel is om de totale tijd die nodig is om individuele items te voltooien te verminderen.

Echter, tegelijkertijd wil je de totale waarde die tijdens de sprint wordt geleverd maximaliseren.

Welke items geef je prioriteit?

Sommige taken moeten gewoon eerst gebeuren, anders kunnen de andere taken simpelweg niet worden opgepakt.

Je kan geen dak plaatsen zonder dat de rest van het huis er staat.

In de praktijk lukt het echter niet altijd dit a) helemaal goed te overzien en b) heb je soms de capaciteit niet om deze structuur van afhankelijkheden aan te pakken binnen de sprint.

Je moet hiervoor dus behoorlijk puzzelen met elkaar.

Het is soms verleidelijk om de “waterfall methode” te gebruiken weergegeven in een Gantt chart bijvoorbeeld.

Dit is een projectmanagement methode waarbij je een nieuwe taak oppakt zodra een oude afgerond is en zie je veel in meer conventioneel projectmanagement gebruikt worden.

In de waterfallmethode zou het niet onlogisch zijn om eerst de fundering te graven, dan het huis te bouwen en dan het dak te gaan maken en plaatsen.

Dit past echter niet echt in scrum of agile projectmanagement. In scrum en agile probeer je zo veel mogelijk vertragingen te voorkomen en waar teamleden vanaf de eerste dag bij het traject werken.

Stel je voor:

De eerste drie dagen werk van een 2-wekelijkse sprint komen volledig voor de rekening van één van de experts in het team (het graven van de fundering). De rest van het team zit dan gewoon met z’n duimen te draaien voordat ze iets kunnen gaan doen.

Ik begrijp dat het voorbeeld wat zwart-wit is; in de waterfall methode zal men ook wel iets nuttigs gaan doen met de teamleden die nog niet nodig zijn.

Het kan echter zijn dat zij zich simpelweg nog bij een ander project begeven in deze fase en alleen langskomen bij het plaatsen van het dak bijvoorbeeld.

Dat brengt meer risico’s mee op vertragingen of bijvoorbeeld miscommunicaties.

Binnen scrum en agile is zoiets ongewenst.

Hoe organiseer je de taken dan?

Je kiest met het team de taken uit waarmee je wil beginnen. Vaak zullen dit dus taken zijn die niet afhankelijk van elkaar zijn.

Daarna, zodra taken afgerond worden, kan je het concept “swarming” toepassen.

Swarming stelt dat zodra iemand een taak af heeft deze persoon gaat helpen bij een ander teamlid/andere taak die uitgevoerd wordt. Er wordt nog geen nieuwe taak opgepakt.

Naarmate teamleden meer en meer afronden kunnen spelen ze zich vrij om bij de andere taken te gaan helpen.

Zo versnelt swarming het afronden van de open taken.

Zodra er geen taken meer zijn, worden nieuwe taken van de sprint backlog verdeeld en herhaald het proces zich. Je krijgt dus een soort “mini sprint” in de sprint.

Wie doet wat in een sprint?

Een terugkerende vraag bij agile en scrum is wie welk werk moet oppakken in een sprint.

Het hangt natuurlijk af van je project en je aanwezige expertises in het team. Een uitgangspunt is dat je zo veel mogelijk “T-shaped” teamleden hebt.

Zij hebben expertise op één werkgebied, maar kunnen ook hun handen laten wapperen op andere werkgebieden waar ze misschien geen expert is zijn.

Een logische spelregel om te volgen is dat een taak wordt opgepakt door iemand die het beste in staat is om de taak snel en correct uit te voeren.

Als deze persoon bezet is, kiest het team wie het vervolgens gaat oppakken.

De daily scrum meeting

De Daily Scrum (ook bekend als de Daily Standup, of Daily Scrum) is een korte meeting waarin de teamleden hun inspanning synchroniseren.

Daily scrums stellen teamleden in staat om ervoor te zorgen dat aan de juiste dingen wordt gewerkt door de juiste mensen op het juiste moment.

Vaak vinden de daily standups in de ochtend plaats bij aanvang van de dag op hetzelfde tijdstip.

Ze duren niet langer dan 15 minuten.

Het hele team moet aanwezig zijn en iedereen gaat staan. Staan zorgt voor extra focus. 

Het is een actieve houding en er is geen kans om niet stiekem ongezien op je scherm te kijken of wat af te maken.

Vaak wordt een timer ingesteld zodat de vergadering niet te lang duurt.

De Scrum Master is de faciliteert de vergadering, maar het is de verantwoordelijkheid van het hele team dat het goed verloopt.

Vaak wordt er een kort rondje gemaakt waarin drie simpele vragen worden beantwoord:

  • Wat heb ik gisteren gedaan om het sprint doel te bereiken?
  • Wat ga ik vandaag doen om het sprint doel te bereiken?
  • Wat belemmert of blokkeert de voortgang om het sprint doel te bereiken?

Hoe communiceer je de voortgang van een sprint?

De Product Owner en misschien ook wel andere andere stakeholders die wat verder van het team staan willen vaak weten hoe de sprint vordert. Hiervoor wordt vaak een burndown chart gebruikt. Die zet de hoeveelheid werk begroot af ten opzichte van de hoeveelheid gerealiseerd werk van de sprint.

Verder geeft een up-to-date Kanban board met daarin alle taken van de sprint vaak ook al een goed idee om een eerste gevoel te krijgen. Lees hier meer over Kanban borden.

Wanneer is je sprint afgerond?

Je stelt vooraf duidelijk vast wat het deal is van de sprint. Je hebt hierbij een aantal userstories of items die je wil afronden.

Deze zijn officieel afgerond wanneer ze voldoen aan de afgesproken “Definition of Done”.

Zodra de sprint voorbij is wordt er in een sprint review met het team, de Product Owner en soms andere stakeholders gekeken de uitkomsten.

Mochten er zaken in je sprint backlog overblijven kan je deze meenemen naar je volgende sprint.

Samengevat: sprints zijn het hart van scrum

De gehele scrum methodiek en agile filosofie zijn structuren om een bepaald type projecten gemakkelijker en beter te kunnen oppakken.

De scrum methodologie is vrij directief. Het zit vol met allerlei procedures die één-op-één opgevolgd moeten worden.

Veel elementen komen de kwaliteit van je project ten goede en helpen risico’s op bijvoorbeeld vertragingen of teleurstellingen bij stakeholders te beperken.

Veel van deze procedures zijn echter niet bepalend voor de uitkomsten. Je kan er veel weglaten of middelmatig uitvoeren en op zich nog steeds een prima project draaien.

Sprints zijn echter de kern van scrum. Hier wordt simpelweg het werkt verzet. Zonder sprints geen scrum.

Plan en organiseer je sprints goed? Dan kan je met jouw team ontspannen werken en haal je de beoogde doelen.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.