Zoals veel van mijn collega’s werk ik ‘in sprints’: er worden door de Product Owner geprioriteerde story’s op een Sprint Backlog gezet en dagelijks worden voortgang en knelpunten daarvan besproken. In mijn huidige team bij een overheidsinstelling wordt nog wel ruimte gelaten voor analyse en oplossen van bevindingen uit productie, en onderhoud aan onze ontwikkel- en testomgevingen.
De sprints duren bij ons vier weken. Door de jaren heen is gebleken dat we hierdoor een goed ritme hebben: het sprintdoel wordt gehaald, of de reden van niet halen is geaccepteerd. Recent kwam toen een luxeprobleem op ons pad: ruim voor het eind van de sprint waren alle story’s en taken af, of wachtten nog slechts op reviewcommentaar.
Een van de kwaliteiten van ons team is dat we leren van onze fouten en voortdurend willen verbeteren. Voorheen werden wel in een vroeg stadium extra story’s aan de sprint toegevoegd omdat we dachten dat wie die ook af zouden krijgen. En kregen we het deksel hard op de neus: de nieuwe story’s niet klaar, en zelfs het eerder beloofde sprintdoel (zeg maar de oorspronkelijke Sprint Backlog) kwam onder druk. Gevolg: veel stress op de laatste dagen, en openstaande story’s dan maar naar de volgende sprint zetten inclusief een handmatige correctie van de Storypoints die al wel gedaan zijn.
Ook in de huidige sprint werd bewust wat minder nieuwe functionaliteit gepland: een nieuwe ontwikkelaar moest worden ingewerkt, een informatieanalist die langdurig ziek is, en onrust en onduidelijkheid vanwege ‘wet DBA’ waardoor er wel of niet kennisoverdracht plaats moest vinden. En dus: minder story’s die testwerk bevatten, en opnieuw een vrij lege Sprint Backlog na twee weken.
Op de backlog stond nog een story met minder hoge prioriteit, en ook die werd vlot ontwikkeld en getest na toevoeging aan de Sprint Backlog. En daarna ontstond een discussie: moeten we alles waar we aan werken ook aan de Sprint Backlog toevoegen?
Enkele collega’s menen van wel: zo is maximaal inzichtelijk waar we aan werken. Ikzelf vind van niet: een dergelijk item (denk aan documentatie, opruimen van oude scripts, omzetten van ontwerpen naar de nieuwe standaard,…) is niet aan de business of Product Owner beloofd, en voortgang en inzicht is prima te melden tijdens de daily standup.
Dit laatste kwam vandaag nog aan de orde tijdens onze Retrospective, en is nu dan ook afgesproken. Mét de toevoeging dat we het wel op de Sprint Backlog zetten als we willen dat er meerdere collega’s naar gaan kijken of aan gaan werken. En uiteraard wordt deze aanpak in de volgende Retrospective weer geëvalueerd!
In het algemeen denk ik dat je dit (luxe-) probleem vooral wilt voorkomen, vooral door goed te kijken of de workload tussen ontwikkelaars en testers goed is verdeeld. Wat daarbij kan helpen is de vraag ‘Heeft iedereen wat te doen? ‘, hoewel dit verre van voorgeschreven wordt in de boekjes. Maar hierdoor kun je wel op het moment van starten van de Sprint een goed (lees: beter) sprintdoel formuleren waar alle teamleden zich aan willen verbinden.
