Scrum voor Business Intelligence – deel 2: Minimale criteria, maximale waarde

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 tweede blogpost gaat in op hoe je ervoor zorgt dat je, binnen een sprint, functionaliteit levert die voldoet aan de wensen van de organisatie. Sleutel daarin is het afstemmen van de criteria waaraan de functionaliteit, minimaal, moet voldoen.

Kleine backlog-items
Een sprint in Scrum is een timebox van maximaal een maand waarbinnen je een potentieel te releasen product incrementeel ontwikkelt. Maar hoe zorg je ervoor dat je een increment levert dat daadwerkelijk te releasen is? Daarvoor is het van belang om met zo klein mogelijke backlog-items te werken die ieder afzonderlijk in een productincrement kunnen worden opgenomen en welke daadwerkelijk waarde aan het product toevoegen. Deze krijg je mede door, zoals in de eerste blogpost beschreven, verticaal te slicen.

Naast dat de backlog-items klein, onafhankelijk en waardevol moeten zijn, zullen ze ook aan bepaalde kwaliteitscriteria moeten voldoen. Deze leg je van tevoren vast in de ‘definition of done’. Zo kun je gedurende de sprint vaststellen wanneer het item aan alle eisen voldoet.

In de definition of done houd je rekening met:
• Eisen die vanuit de beheerorganisatie worden gesteld aan producten die gereleased worden. Bijvoorbeeld:
    • Dataleveringsovereenkomsten met de aanleverende systemen
    • Release-documentatie
    • Load performancetest documentatie
• Kwaliteitseisen die je als team aan je oplossing stelt. Hierbij geldt doorgaans: hoe volwassener het team, des te uitgebreider zullen deze eisen zijn. Een volwassener team heeft meer op orde en zal gemakkelijker aan deze kwaliteitseisen kunnen voldoen. Voorbeelden van dergelijke eisen zijn:
    • Definities van alle meetwaarden zijn vastgelegd in een data dictionairy
    • Alle items zijn getest door een tweede persoon binnen het team
    • Alle rapporten voldoen aan de rapportagestandaarden
• De acceptatiecriteria die vanuit de organisatie aan het product worden gesteld. Deze acceptatiecriteria zijn de waarborgen om ervoor te zorgen dat er daadwerkelijk waarde geleverd wordt.

De juiste criteria
De uitdaging ligt in het slim opstellen van deze definition of done. Enerzijds wil je voldoende criteria opnemen om de kwaliteit en daarmee het succes van je product te bewaken. Anderzijds wil je voorkomen dat het voldoen aan deze criteria onnodig veel werk met zich meebrengt, want dan wordt je item alsnog te groot om in een sprint te behappen.

Daarom is het goed jezelf af te vragen of er geen onnodig papierwerk wordt verlangd. Als je bijvoorbeeld ETL- of rapportagedocumentatie oplevert ten behoeve van andere ontwikkelaars, is het wellicht veel efficiënter en effectiever om te werken met commentaarregels in de code en coding conventies die de leesbaarheid van de software vergroten.

De grootste winst is echter vaak te behalen in het beter afstemmen en formuleren van de acceptatiecriteria. De focus moet hierbij liggen op de minimale functionaliteit die het item moet bieden om toegevoegde waarde te brengen. Laat je dus bijvoorbeeld niet verleiden om in de acceptatiecriteria voor een rapport layoutdetails op te nemen, tenzij het voldoen aan deze layoutdetails strikt noodzakelijk is (vanwege bijvoorbeeld regelgeving). Probeer de acceptatiecriteria zo te formuleren dat ze de nodige vrijheid bieden aan het team om met eigen oplossingen te komen.
Maar zorg er wel voor dat de criteria eenduidig kunnen worden getoetst. Ga bijvoorbeeld samen met de product owner na welke nieuwe inzichten het rapport zou moeten bieden: welke specifieke vragen gaat het rapport beantwoorden (want welke keuzes kunnen er op basis van deze informatie dan beter worden gemaakt)? Het gaat er immers niet om iets te leveren dat aan vooraf gedetailleerde specificaties voldoet maar om iets te leveren dat toegevoegde waarde voor de organisatie biedt.