De lengte van een sprint is altijd een discussiepunt bij de aanvang van een scrumproject. Er wordt bij de start van een project vaak gekeken naar de scrum guide, die een sprintlengte adviseert van een maand of minder.
Als team kom je dan gemakkelijk in de verleiding om uit te gaan van sprints van vier weken, zodat je zo min mogelijk tijd kwijt bent aan het proces. Dat is zeker aan het begin van het proces best begrijpelijk; in de eerste sprints worden immers belangrijke keuzes gemaakt, die de basis leggen voor de rest van het project. Omdat dit nogal wat uitzoekwerk vergt, is de verleiding groot om een sprintlengte van vier weken aan te houden.
Inschatten
Toch is er ook iets voor te zeggen om, ook vanaf het begin, te werken met sprints van twee weken. De belangrijkste reden is dat korte sprints beter zijn te overzien en daardoor makkelijker in te plannen dan langere sprints. Het is vaak wenselijk dat je als team voorspelbaar oplevert en daarvoor is het belangrijk dat je in een bepaalde cadans komt. Pas als je weet wat je tijdens een sprint kunt opleveren, is het mogelijk om vijf of tien sprints vooruit te plannen.
Aan het begin van het project, als de teamleden elkaar nog niet goed kennen en er nog niet is uitgekristalliseerd wat het werk precies gaat inhouden (nog niet alle keuzes zijn dan al gemaakt), is het vooral belangrijk om goede inschattingen te kunnen maken. Kiezen voor tweewekelijkse sprints helpt daarbij, omdat je deze beter kunt overzien en daardoor makkelijker kunt plannen.
Uitstelgedrag
Daarnaast komt het in het begin van een project vaak voor dat sprints niet gehaald worden. Als je met periodes van vier weken werkt, is de impact van het niet halen van de sprint groter dan wanneer je kiest voor twee weken.
Echter misschien nog wel belangrijker; korte sprints van twee weken houden teamleden scherper. Wie nog vier weken de tijd heeft om aan een sprint te werken, heeft nu eenmaal eerder de neiging om taken nog even uit te stellen. Periodes van twee weken zijn veel beter te overzien en als teamlid zul je eerder geneigd zijn om vandaag alvast te beginnen. Bovendien kan de product owner dan ook sneller schakelen als blijkt dat de prioriteiten tussendoor zijn veranderd; hij of zij hoeft dan hooguit twee weken te wachten voordat de gewenste wijziging wordt doorgevoerd door het developmentteam.
Overwerk
Wat je tenslotte ook wel eens ziet gebeuren binnen teams, is de neiging om over te werken, om er zeker van te zijn dat een sprint wordt gehaald. Maar eigenlijk is overwerken niet veel anders dan ‘stiekem de sprint langer maken’, met als enige doel om de verwachtingen waar te maken. Als blijkt dat dit gebeurt, dan is het belangrijk om dit te accepteren en de volgende sprint wat beter in te schatten. Immers: als er tijdens een bepaalde sprint sprake is geweest van overwerk, dan kun je ervan uitgaan dat dat bij volgende sprints ook weer gaat gebeuren.
Mocht blijken dat er tijdens een sprint is overgewerkt (en het werk dus eigenlijk niet goed is ingeschat of gepland), dan kun je er dus voor kiezen om de volgende sprint langer te maken of om extra capaciteit in te schakelen – dus het team groter te maken.
Kortom: korte sprints van twee weken houden teamleden scherper, maar ook flexibeler. Tweewekelijkse sprints zijn bovendien beter in te plannen en maken de kans groter dat de verwachte user stories ook daadwerkelijk kunnen worden opgeleverd. Een sprintlengte is iets om te respecteren, dus is het belangrijk om deze niet stiekem groter te maken, bijvoorbeeld door over te werken.
Erik Herlaar, scrum master bij Ilionx
Ik denk dat je Scrum Agile aan moet pakken, dus flexibel en wendbaar. Zonder regels, kijken hoe het komt. Het hangt er wat van af om wat voor soort ICT werk het gaat (nieuwbouw, onderhoud, welk gebied) maar soms heb je de geest, en ook tijddruk komt voor, dan is er helemaal niets mis met overwerk. Dat is de aard van het werk, het is niet op de minuut voorspeelbaar met onzekerheden. Je weet het niet altijd en soms zin er digitale beren op de weg.