Scrum voor Business Intelligence – deel 3: Aanmodderen is geen optie

Business Intelligence is complex. Je hebt enerzijds te maken met snel veranderende informatiebehoeften. Anderzijds heb je te maken met verschillende bronsystemen en een vaak onvolledig zicht op de kwaliteit en beschikbaarheid van de data. Daarnaast zorgt nieuwe technologie voor nieuwe mogelijkheden, maar brengt de invoering daarvan weer nieuwe complexiteit met zich mee.

Scrum is een raamwerk dat gebruikt wordt om werk aan complexe producten te managen. Het is daardoor goed toepasbaar in een Business Intelligence omgeving. De grote kracht van Scrum zit in de eenvoud van het raamwerk, maar het succes is afhankelijk van een goede toepassing hiervan. Hoe pas je Scrum toe in een Business Intelligence omgeving? Wat zijn de valkuilen en de tips?
In deze serie blogposts deel ik mijn inzichten op dit gebied. Iedere blogpost gaat in op een bepaald onderwerp: van het opstellen van user story’s tot de rol van de product owner en van de manier waarop je plant tot de rol van architectuur. Waar mogelijk zal ik daarbij ingaan op de specifieke zaken waar je in een Business Intelligence omgeving tegenaan loopt. Deze derde blogpost gaat over hoe je om gaat met sprint backlog items die je in de sprint niet hebt kunnen afronden.

Not done
In de vorige blog post beschreef ik hoe je, door het zorgvuldig opstellen van de definition of done, enerzijds de kwaliteit van je increment bewaakt en anderzijds de haalbaarheid van je backlog items vergroot. Toch zal het ook bij zeer volwassen Scrum teams weleens voorkomen dat niet alles wat voor een sprint gepland staat ook daadwerkelijk in die sprint wordt gerealiseerd. Een of meerdere van de sprint backlog items voldoen aan het eind van de sprint dan niet aan de definition of done, oftewel deze items zijn “not done”.

Wanneer een sprint backlog item aan het eind van de sprint niet aan alle criteria voldoet zijn er twee logische beslissingen die je als Scrum team kunt nemen:
• Je “reject” het item omdat het niet mogelijk blijkt te zijn dit tegen acceptabele inspanning te realiseren. Eventueel voeg je een nieuw item aan de product backlog toe om het gat in functionaliteit dat hierdoor ontstaat op termijn op een andere manier in te vullen.
• Je plaatst het item terug op de product backlog zodat deze in een volgende sprint, op basis van eventueel herziene prioriteit, weer kan worden opgepakt. Uiteraard zal je bij het inplannen van dit item voor een volgende sprint wel moeten afvragen of het dan wel een haalbare kaart is.
De product owner maakt deel uit van het Scrum team en beslist hier uiteraard over mee.

Splitsen aan het eind van de sprint
In de praktijk kom ik weleens de vraag tegen: “Kunnen we dit item niet opsplitsen in twee delen, waarbij we het eerste deel als afgerond beschouwen, en het tweede deel naar de volgende sprint overhevelen?”
Reden van deze vraag vanuit het team is vaak dat het team toch wel de credits wil krijgen voor het werk dat men in de sprint heeft gedaan. Een veel gehanteerde performance indicator in Scrum is immers de hoeveelheid geleverde functionaliteit.

Er zijn echter verschillende redenen waarom dat geen goed idee is:
• In Scrum stuur je niet op effort. Een sprint is immers time boxed en fixed. In Scrum wil je sturen op gerealiseerde waarde. Een halffabricaat levert echter (nog) geen nieuwe waardevolle functionaliteit op.
• Een halffabricaat is lastig te inspecteren. Wanneer je bijvoorbeeld een backend met data-extractie oplevert maar geen bijbehorend rapport, is het veel lastiger om te controleren of de geleverde functionaliteit wel correct is. Je splitst de functionaliteit dan immers niet verticaal, maar horizontaal. Waarom je wel verticaal zou moeten slicen kun je overigens in de eerste blog van deze serie teruglezen.
• Als het item echt in twee delen is op te splitsen die afzonderlijk waarde aan het product toevoegen, dan zou het beter zijn geweest deze splitsing al vooraf te maken. Door nu op het eind van de sprint overhaast alsnog te gaan splitsen zie je wellicht zaken over het hoofd.
• Als je het item niet splitst, maar gewoon als niet af beschouwt, krijgt het team er nu ook geen credits voor. Het team, inclusief product owner, zal dan een volgende keer extra gemotiveerd zijn om niet te veel user story’s in te plannen en te grote user story’s waar mogelijk op te splitsen. Het team leert en verbetert. En continu verbeteren, inspecteren en aanpassen, is een van de belangrijkste principes achter Scrum.

Het is overigens ook niet zo dat “not done” sprint backlog items automatisch doorschuiven naar de volgende sprint. Er kunnen immers inmiddels andere prioriteiten zijn waardoor eerst andere items worden opgepakt. Iedere sprint is immers een soort miniproject met een eigen prioritering, planning, uitvoering en retrospective. Aanmodderen, het automatisch doorschuiven van (delen van) een item naar een volgende sprint, is dan ook geen optie!