scrummaster.nl

“We zijn een team van 5 en we werken aan een 10-daagse sprint. De afgelopen 5 sprints is het ons niet gelukt om 100% van de User Stories af te hebben. Het zit meer rond de 60-70%. Er ligt een voorstel om de sprint lengte te verlengen naar 15 dagen ‘want de sprint review en sprint planning elke 10 dagen is veel overhead” [bron]

Het team wil dus graag de lengte veranderen naar 15 dagen, maar de vragensteller vroeg zich af of het verlengen van de sprint er wel voor zou zorgen dat het werk wél of zou komen. Tenslotte lukte het al niet in een kleine periode, dus waarom dan in een langere periode wel?

De trend lijkt te zijn om steeds naar kortere sprints te gaan. Daar waar de Scrum literatuur 30 kalender dagen voorschrijft lijkt de huidige opinie te zijn dat twee weken al bijna te lang is. Sterker nog, waarom überhaubt nog sprints? In Kanban worden ze helemaal weg gelaten en gaat het helemaal om ‘flow’.

Tegen de trend in zou ik juist willen adviseren om langere sprints te gebruiken, van vier weken, het dichtste bij de 30-dagen standaard lengte.

Een vier-weken-sprint is een ideale lengte om een ritme op te bouwen van ‘plannen-op gang komen-stormen-uitrusten’. Het is erg prettig om aan het begin de sprint de tijd te hebben om gedegen naar de sprint inhoud te kijken en een goede sprint planning vast te kunnen stellen.

Natuurlijk kan je de tijd halveren die je reserveert als je twee weken gebruikt, maar geeft dat hetzelfde resultaat? Je hoeft theoretisch ook maar de helft van de items te behandelen, toch merk ik dat er altijd items zijn die in meer en mindere mate aandacht behoeven tijdens een sprint planning. Door juist de tijd te hebben om aan de moeilijkere items met het team aandacht te geven kwamen we tot een goed gedeeld inzicht en planning. Je doet jezelf tekort als je te weinig tijd geeft.

Net als op maandag, of na een vakantie, moet je weer even op gang komen. Omdat je weet dat het doel van de sprint vast staat en het geheel haalbaar zou moeten zijn kan je beginnen met wat laaghangend fruit. Er is niet bevredigender dan op de eerste dag al één of meerdere kleine taken of zelfs items af te kunnen vinken en het helpt je om snel weer in de op gang te komen en als team te gaan stormen.

Aan het einde van de sprint slaat de vermoeidheid toe, maar gelukkig zijn dan er dan rituelen zoals de Sprint Review en de Retrospective. Deze rituelen helpen om weer tot rust te komen, tot bezinning te komen om te bepalen waarheen en hoe we nu verder gaan.

Je wilt bij de Sprint Review graag publiek hebben dat komt kijken. Niet alleen helpt het publiek de Product Owner om nieuwe ideeën op te doen, het draagt ook uit dat het geld dat de afgelopen periode gespendeert is in ieder geval tot een resultaat geleid heeft. En als het team trots is wat het gedaan heeft is het een opkikker om het te demonstreren.

Het soort mensen dat je graag wilt hebben zijn vaak drukbezet en deze hebben geen tijd voor en interesse in een demonstratie met weinig toegevoegde functionaliteit. Ze zullen een terugkerende afspraak elke twee weken al te veel vinden, maar zeker als wat ze zien veranderen steeds maar een klein beetje is, en snel afhaken.

Mocht je in de luxe zijn dat je echte gebruikers hebt die je product daadwerkelijk na een sprint moeten gaan gebruiken dan is het maar de vraag of zij zitten te wachten op elke twee weken een nieuwe versie van je software, ze moeten namelijk ook gewoon hun werk doen en willen helemaal niet te veel gestoord worden in hun activiteiten. Niemand heeft er zin in om steeds weer te moeten ontdekken hoe het nu werkt of een incomplete set functionaliteit te ontvangen.

Met een vier wekelijkse sprint laat je ook toe om een Retrospective te houden met afdoende lengte – zeg minimaal twee uur. Bij kortere sprints ga je óf kortere retrospectives houden óf je gaat ze elke paar sprints doen.

Het gevolg van de eerste keuze – kortere retrospectives – is dat je niet de diepte zal bereiken die nodig is voor een effectieve retrospective, en het nadeel van een retrospective om de twee sprints is dat de eerste sprint toch weer ver weg lijkt, ook al gaat het uiteindelijk om dezelfde kalender periode.

En wat zou het team moeten doen die hun sprintdoel niet haalt? Nog eens goed kijken wat er niet gebeurt tijdens hun Daily Scrum. Het doel van de Daily Scrum is om als team er voor te blijven zorgen dat het sprint doel gehaald gaat worden en met vier weken is er genoeg tijd om te signaleren dat het minder optimaal verloopt en adequaat te reageren.