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!
7 - 9 juni 2023Praktische driedaagse workshop met internationaal gerenommeerde spreker Alec Sharp over herkennen, beschrijven en ontwerpen van business processen. De workshop wordt ondersteund met praktijkvoorbeelden en duidelijke, herbruikbare richt...
12 t/m 14 juni 2023Praktische workshop met internationaal gerenommeerde spreker Alec Sharp over het modelleren met Entity-Relationship vanuit business perspectief. De workshop wordt ondersteund met praktijkvoorbeelden en duidelijke, herbruikbare rich...
13 - 15 juni 2023Praktische driedaagse workshop met internationaal gerenommeerde trainer Lawrence Corr over het modelleren Datawarehouse / BI systemen op basis van dimensioneel modelleren. De workshop wordt ondersteund met vele oefeningen en praktijk...
21 - 23 juni 2023 (3 ochtenden online)Praktisch seminar met Barry Devlin over Data Mesh, -Fabric en -Lakehouse Data fabric, data mesh en data lakehouse bieden verschillende technologische oplossingen voor digitale transformatie. Inzicht in deze benad...
9 oktoberPraktische dag met internationaal gerenommeerde trainer Keith McCormick over automated machine learning en explainable AI. This one-day workshop explores how data teams can leverage automated machine learning and which phases of the machine ...
10 en 11 oktober 2023 Organisaties hebben behoefte aan data science, selfservice BI, embedded BI, edge analytics en klantgedreven BI. Vaak is het dan ook tijd voor een nieuwe, toekomstbestendige data-architectuur. Dit tweedaagse seminar geeft antwoor...
12 oktober 2023 Praktisch en interactief seminar met Nigel Turner Data-gedreven worden lukt niet door alleen nieuwe technologie en tools aan te schaffen. Het vereist een transformatie van bestaande business modellen, met cultuurverandering, een heron...
31 oktober 2023 Praktische workshop Datavisualisatie - Dashboards en Data Storytelling. Hoe gaat u van data naar inzicht? En hoe gaat u om met grote hoeveelheden data, de noodzaak van storytelling en data science? Lex Pierik behandelt de stromin...
Deel dit bericht