“Zullen we de sprint naar drie weken brengen?” Ik hoor de vraag met enige regelmaat, en onlangs weer, bij een team dat ik begeleid. De aanleiding is bijna altijd dezelfde: het knelt ergens, en een langere sprint voelt als lucht. Maar in mijn ervaring gaat de discussie over sprintlengte zelden over sprintlengte. Het is een symptoomdiscussie, en dat maakt ‘m juist interessant.
De aanleiding
De situatie bij dit team, en die zul je herkennen: over een kwartaal gemeten wordt ongeveer 40 procent van de geplande resultaten gehaald. Er komt veel ad-hoc werk tussendoor. En de twee Product Owners hebben naast hun PO-rol een flink pakket andere taken, waardoor elke twee weken een volle ronde sprintrituelen (refinement, planning, review, retro) stevig drukt op hun agenda.
De redenering richting drie weken is dan snel gemaakt: minder ceremonies per maand, meer aaneengesloten tijd om werk af te ronden, meer ademruimte voor de PO’s. Klinkt logisch. En toch is het meestal niet het antwoord.
Wat je verliest bij een langere sprint
Een langere sprint heeft een prijs, en die wordt in de discussie vaak vergeten. Je hebt minder feedbackmomenten, dus fouten en verkeerde aannames leven langer voordat iemand ze ziet. Je hebt minder momenten om prioriteiten bij te stellen, terwijl juist een omgeving met veel ad-hoc werk vraagt om vaak kunnen bijsturen. En de rekensom van “minder ceremonies” valt in de praktijk tegen: een sprint van drie weken vraagt een langere planning, een vollere review en een zwaardere refinement. De overhead verschuift meer dan dat ‘ie verdwijnt.
De belangrijkste observatie: het ad-hoc werk verdwijnt niet door de sprint te verlengen. Het krijgt alleen een langere periode om doorheen te waaien.
Mijn uitgangspunt: twee weken
Voor de duidelijkheid: ik heb wel degelijk een voorkeur. Twee weken is voor mij het uitgangspunt. Eén week is meestal te kort: de overhead van de events weegt zwaar en er is nauwelijks ruimte om echte waarde te creëren. Drie of vier weken is te lang om bij te sturen, zeker in een omgeving waar veel verandert. Twee weken zit daar precies tussen: net lang genoeg om iets af te maken, net kort genoeg om wendbaar te blijven.
Maar een uitgangspunt is geen wet. Wat uiteindelijk zwaarder weegt: is het werkbaar voor de groep, en vooral voor de Product Owners? En in welke context zit je? Dat gesprek is belangrijker dan het getal.
Kijk verder dan het team: de waardestroom
Er is nog een argument dat in deze discussies vaak vergeten wordt: een team kiest zijn cadans niet alleen. Werk je binnen een waardestroom of Agile Release Train met meerdere teams, dan is een gedeelde cadans geen formaliteit maar de motor onder de samenwerking. Sprints die gelijk lopen betekenen synchronisatiemomenten die kloppen: gezamenlijke planningen, demo’s op hetzelfde ritme en afhankelijkheden die je per sprint kunt afstemmen.
Eén team dat in z’n eentje naar drie weken gaat, breekt dat ritme voor iedereen. De vraag “welke sprintlengte past bij ons team?” is dan eigenlijk de verkeerde schaal. De echte vraag is: welke cadans past bij de waardestroom, en wat heeft dit team nodig om binnen dat ritme goed te functioneren?
De echte vragen
Als een team structureel 40 procent van de planning haalt, is de sprintlengte zelden de oorzaak. De vragen die er wel toe doen:
Wordt er realistisch gepland? Een team dat kwartaal na kwartaal minder dan de helft haalt, plant structureel te veel. Plan op wat het team aantoonbaar aankan, niet op wat er in de backlog past.
Is het ad-hoc werk zichtbaar? Onvoorzien werk dat er “gewoon tussendoor komt” hoort expliciet in de planning: reserveer er capaciteit voor. Dan is het geen verstoring meer, maar een ingecalculeerd deel van de sprint.
Wat doen we aan de belasting van de Product Owners? Als PO’s hun rol niet kunnen pakken door neventaken, is dát het probleem. Een langere sprint geeft ze hooguit tijdelijk lucht; het lost niet op dat de rol klem zit.
Hoe maak je dit bespreekbaar?
Als een team of PO zelf vraagt om een andere cadans, zie ik dat vooral als een cadeau: er is pijn, en die wordt hardop uitgesproken. De slechtste reactie is een snel ja of nee. Wat ik doe: de vraag verwelkomen, en ‘m dan uitpakken. Wat knelt er precies? Vaak blijkt het antwoord niets met de kalender te maken te hebben: de planning is te vol, het ad-hoc werk is onzichtbaar, of de PO zit klem tussen rollen.
Blijft de wens daarna bestaan, maak er dan een experiment van in plaats van een besluit. Spreek een pilot af van drie of vier sprints, bepaal vooraf waar je op let (halen we meer van de planning? krijgen de PO’s echt lucht? blijft de feedbackkwaliteit overeind?) en evalueer eerlijk. En betrek de waardestroom erbij: een cadanswijziging raakt meer teams dan het jouwe.
Mijn conclusie
Een langere sprint kan een symptoom verzachten, maar lost de onderliggende oorzaak zelden op. In organisaties die continu veranderen is een korte feedbackcyclus juist je grootste bezit. Investeer liever in realistisch plannen, expliciete ruimte voor onvoorzien werk en het ontlasten van de Product Owner dan in een langere sprint.
De volgende keer dat de sprintlengte-discussie oplaait, is mijn advies dan ook: verwelkom de vraag, parkeer het getal, en vraag door naar wat er eigenlijk knelt. Dat gesprek levert vrijwel altijd meer op dan de kalenderwijziging zelf.
Sparren over dit soort dilemma’s in jouw team of organisatie? Plan een vrijblijvende kennismaking via https://pivitconsultancy.nl/#contact.