Geplande en ongeplande werkzaamheden in Scrum
De meeste teams die beginnen met Scrum, begrijpen hun backlog en het zogenaamde „gepland werk". Dat is het werk dat iedereen samen heeft verzameld en volledig heeft begrepen. En dan is er nog al het andere… Hier moeten nieuwe Scrum Teams in hun eerste Sprint op letten. Alles wat ze naast het geplande werk voor die Sprint doen, wordt met het aantal uren dat ervoor nodig was in de kolom „ongepland werk" opgenomen.
Na de eerste Sprint zijn teams vaak totaal verrast door hoeveel er bij elkaar komt. Meestal gaat het om verschillende taken die je al sinds mensenheugenis elke dag of elke week uitvoert – we noemen ze vaak „Business-as-Usual"-taken (BAU), maar ze kunnen bij andere organisaties ook anders heten. Daarnaast zijn er ad-hocmeetings en andere dingen die we doen zonder er echt bij na te denken. Dat kunnen BAU-taken zijn, of gewoon verstoringen en onderbrekingen.
En dan zijn er nog de noodgevallen die meteen opgepakt moeten worden. Vaak valt dit onder „support" – maar het kan net zo goed een andere naam hebben.
Sommige van deze dingen kennen we al bij de Sprint Planning. Dan voeg je ze toe aan je Sprint Backlog als onderdeel van de commitments. Als ze steeds weer opduiken, is het misschien slim om er een eigen kolom voor aan te maken en een bepaalde capaciteit voor deze dingen te reserveren.
Wat doe je bij ongepland werk in Scrum?
Plan een meeting in om de terugkerende taken nader te bekijken en te ontdekken hoe je het werk ermee kunt verbeteren. Het doel is om ze te automatiseren of ze op zijn minst zo veel mogelijk te verminderen.
De items die je niet in de Sprint Planning kunt meenemen, zijn items die pas tijdens de Sprint opkomen en niet voorzien kunnen worden. We noemen ze "unplanned" oftewel "ongepland". Elk team heeft een aantal van deze ongeplande werkzaamheden en moet uitzoeken hoe het daarmee omgaat. Ook hier is het goed om regelmatig na te denken over wat je kunt doen om deze ongeplande werkzaamheden zo veel mogelijk te verminderen. Hoe meer ongepland werk een team heeft, hoe minder werk je er nog extra bij kunt nemen. Idealiter zou het grootste deel van het werk van een Scrum Team gepland werk moeten zijn. Elk team moet zijn capaciteit inschatten en uitzoeken hoe je daar het beste mee kunt werken.
Dit zijn enkele methoden die ik al bij teams heb gezien:
Grenzen en regels
Al het ongeplande werk wordt op het board genoteerd en geprioriteerd. De Work-in-Progress-kolom heeft echter een limiet voor hoeveel werkzaamheden tegelijkertijd opgepakt mogen worden, bijvoorbeeld twee stuks. Er mag dus tegelijkertijd maar aan twee verschillende dingen gewerkt worden. De rest van het team kan zich zo op het geplande werk voor de Sprint concentreren. Je kunt ook regels opstellen over welke ongeplande items op het board geschreven mogen worden en wanneer etc.
Eén persoon per dag/week/Sprint
Je kunt ook een planning maken die aangeeft wie wanneer is ingeroosterd om aan ongeplande dingen te werken. Ook zo kan de rest van het team zich op het geplande werk concentreren. Als diegene iets niet begrijpt of een probleem heeft, kan hij of zij de andere teamleden om hulp vragen. Je kunt hierbij dagelijks, wekelijks of per Sprint rouleren.
Een bepaald tijdvenster
Je kunt ook een tijdvenster voor ongepland werk vaststellen. Dat kan bijvoorbeeld tussen 09:00 en 11:00 uur zijn, de rest van de werkdag is dan gereserveerd voor de Sprint Items.
Vaste dagen
Je kunt ook bepaalde weekdagen inplannen voor het werken aan ongeplande dingen – bijv. dinsdag en donderdag. Alle andere werkdagen zijn alleen voor gepland werk bedoeld.
Scrum Teams kunnen rouleren
Als meerdere Scrum Teams aan dezelfde Backlog werken, kunnen de teams onderling rouleren met het werken aan ongeplande dingen. Team A werkt deze Sprint dus alleen aan ongeplande items en Team B werkt aan de Backlog Items.
Je hebt vast gemerkt dat de teams in alle voorbeelden een concrete tijdspanne krijgen voor het werken aan de Backlog Items. Er is geen vast patroon voor en er zijn zeker nog meer mogelijkheden dan de hierboven genoemde. Mocht je dit probleem ook hebben, probeer dan gewoon een paar van deze suggesties uit en ontdek wat voor jou het beste werkt.
Deze tekst komt uit de blog van Growing Agile en is ons ter beschikking gesteld.
