Zo nu en dan valt het mij in mijn rol als scrum master wel eens op dat het implementeren van een user story langer duurt dan verwacht. Daar kunnen meerdere redenen voor zijn, maar bij eentje wil ik in deze blog even stil staan: “Scope creep”.
Wat is scope creep?
Met scope creep bedoel ik in deze blog dat de afgesproken scope van een user story wordt uitgebreid tijdens de werkzaamheden aan deze story. Deze uitbreiding vindt plaats zonder dat hier formele besluitvorming of herprioritering tegenover staat. Het begint vaak onschuldig: een extra knop, andere kleur, extra scherm. Alles onder het motto: “dit doe ik er wel even bij”. De werkzaamheden die onbedoeld extra worden uitgevoerd zijn klein. Soms lijkt het ook handig om de werkzaamheden nu direct even te doen, nu het team net met die ene feature bezig is.
Alle goede bedoelingen ten spijt ondermijnt dit:
- Focus – het team weet niet meer de hoofd- van de bijzaken te onderscheiden.
- Voorspelbaarheid – De velocity wordt onbetrouwbaar, omdat het team meer werk verzet dan waarvoor de user story was ingeschat.
- Moraal – Het werk lijkt niet af te komen, tijdens de wedstrijd wordt de finish steeds verplaatst.
Hoe ontstaat scope creep?
Scope creep komt vaak voort uit goede bedoelingen en is in mijn ogen zelden het gevolg van onwil. Het kan bijvoorbeeld komen van ontwikkelaars die denken: “Als ik hier toch zit, dan pak ik die andere user story ook direct even mee”. Dit leidt er toe dat twee user stories in één keer worden opgepakt. De schatting van beide stories kloppen niet meer en de change wordt groter. Niet alleen een ontwikkelaar heeft hier last van, ook andere teamleden die bijvoorbeeld de wijzigingen moeten testen of handleidingen moeten bijwerken zullen hierdoor worden verrast.
Echter ontstaat scope creep niet alleen door factoren binnen het ontwikkelteam, maar kan het ook zijn dat stakeholders vergeten zijn om in het proces van refinement of het aanleveren van requirements zaken zijn vergeten te noemen. Het kan ook zijn dat een product owner tijdens de sprint zijn of haar inzichten bijstellen en daarmee de acceptatiecriteria wijzigen. Of misschien zijn er helemaal geen acceptatiecriteria aanwezig wanneer er aan een user story wordt ontwikkeld. Het uitblijven van een duidelijke Defintion of Done kan ervoor zorgen dat user stories onduidelijk zijn beschreven, wat weer kan leiden tot scope creep.
Als laatste kan de cultuur binnen het team scope creep bevorderen. Op het moment dat teamleden behulpzaam willen zijn en “dit en dat er nog wel even bijnemen” kan er van de scope van een user story afgeweken worden. Het helpt niet als teamleden geen “nee” of “niet nu” durven te zeggen. Zowel tegen elkaar als tegen de product owner.
Hoe herken ik scope creep?
Er zijn een aantal signalen die wijzen op een mogelijk ontstaan van scope creep:
- User stories blijven lang in progress hangen, zonder dat deze daadwerkelijk tot een afronding komen.
- Twee of meerdere user stories worden tijdens de sprint samengevoegd tot één grote user story. Dit kan zelfs gebeuren door user stories van de product backlog in de sprint te betrekken.
- Het team voert taken uit die niet op de sprint backlog staat en/of nergens beschreven of besproken is.
Wat doe ik als scrum master aan scope creep?
Eerlijk is eerlijk, als scrum master kan ik niet altijd in mijn eentje beoordelen of het werk dat de ontwikkelaars uitvoeren scope creep is of niet. Soms is het extra werk bijvoorbeeld nodig om de kwaliteit van de software te garanderen. Daarom probeer ik altijd alert te blijven op de eerder genoemde signalen. Wanneer ik deze herken probeer ik door te vragen op waarom het team bepaalde werkzaamheden uitvoert. Op basis van het gesprek dat daarmee ontstaat probeer ik te onderzoeken of er andere manieren zijn om met het werk dat het team “extra” doet om te gaan.
Een aantal vragen die je zou kunnen stellen tijdens de daily scrum zijn:
- Stond dit onderdeel in de oorspronkelijke user story?
- Is dit volgens de Definition of Done / Acceptatiecriteria? Of doen we nu meer dan de bedoeling is?
- Als we dit extra werk nu niet doen, wat is daarvan dan het gevolg?
- Als we het werk niet per se nu hoeven doen? Kunnen we het dan ook in een nieuwe user story opnemen en later oppakken?
Het is ook goed om hier in de retrospective aandacht aan te besteden. Zo kan het team leren in de toekomst anders te reageren op de oorzaken van scope creep.
Kan je scope creep ook voorkomen?
Helemaal voorkomen kan je het waarschijnlijk niet, maar je kan wel voorzorgsmaatregelen nemen om scope creep voor te zijn. Zo werk ik als scrum master graag met een Defintion of Ready en een Definition of Done. Dit geeft kaders waaraan de kwaliteit van een user story en het werk van het ontwikkelteam kunnen worden getoetst. Dit moet duidelijkheid bieden voor het ontwikkelteam, zodat zij uiteindelijk weten wat er moet gebeuren als een user story in een sprint wordt opgenomen.
De sprint backlog is vervolgens “heilig”. Deze mag natuurlijk wel veranderen gedurende de sprint, maar in principe moeten deze veranderingen wel besproken worden met het hele team, inclusief de product owner. Hiervoor moeten teamleden wel het gevoel hebben dat ze veilig kunnen aangeven dat iets buiten scope valt. De product owner en stakeholders moeten hier begrip voor op kunnen brengen. Het is niet de bedoeling dat stakeholders stiekem langs de zijlijn proberen om extra werk het ontwikkelteam in te duwen.
Tot slot: goed is goed genoeg
In een context waarin je werkt met een agile framework draait het niet om perfectie, maar om waarde leveren in kleine stappen. Scope creep verstoort dit.
Blijf bij de daily scrums vragen stellen als “Hoort dit bij de afgesproken story?” Of directer: “Volgens mij hebben we nu last van scope creep, of niet?” Op deze manier hoop ik als scrum master een bijdrage te leveren aan het voorkomen of indammen van scope creeps.
Als laatste heb ik nog een paar tips:
- Herken jij scope creep in je team? Bespreek het met je team, bijvoorbeeld tijdens de retrospective.
- Heb je nog geen explicitiete Definition of Done? Tijd om er samen met je team eentje te maken!
- Stel vragen tijdens de daily scrum om erachter te komen of er werk wordt gedaan dat niet op de sprint backlog staat.
Zin om door te praten of jouw ervaringen te delen? Laat dan hieronder een reactie achter of stuur me een berichtje op Bluesky.
Header photo by Unsplash from Freerange Stock
Geef een reactie