Scrum Artefacten

De mate van zekerheid of de scope van het oordeel dat per sprint opgeleverd wordt, is afhankelijk van de verrichte werkzaamheden gedurende sprint. De werkzaamheden die verricht worden gedurende een sprint zijn afhankelijk van welke werkzaamheden of ‘User stories’ op de ‘backlog’ gezet zijn. De ‘backlog’ is te vergelijken met een ‘To do’ lijst voor het scrum team dat werkzaam is voor een specifieke opdracht (Schwaber & Sutherland, 2016). Er zijn twee soorten backlogs, namelijk op het niveau van het product of audit en op het niveau van een sprint. De inhoud van deze backlogs wordt bepaald op basis van risico analyses zoals in Schema 2 weergeven.

Op het product backlog of in dit geval het audit backlog staan alle requirements waaraan het oordeel in de vorm van een rapportage zal moeten voldoen. Deze requirements worden

gedefinieerd door de uiteindelijke gebruiker van de audit rapportages en zullen derhalve gericht zijn op de betrouwbaarheid en relevantie van het oordeel. Werkzaamheden die gericht zijn op relevantie en betrouwbaarheid betreffen bij audit de functionele requirements. De betrouwbaarheid

requirements zijn met name gebaseerd op de eisen die voortkomen uit de standaarden, zoals risico inschattingen en documentatievereisten ten aanzien van planningsoverwegingen. De relevantie requirements zijn met name gericht op de scope, het bepalen van het werkprogramma en de diepgang van werkzaamheden.

Niet functionele requirements zijn werkzaamheden die verricht dienen te worden om de werkzaamheden ten aanzien van functionele requirements mogelijk te maken of efficiënt en effectief te laten verlopen. Voorbeelden van niet functionele requirements zijn het klaarzetten van een dossier ten behoeve van documentatie vereisten, het plannen en maken van afspraken met de auditee verantwoordelijke voor het object van onderzoek voor onder andere het verkrijgen van audit documentatie. Het plannen en maken van afspraken kan ook in de vorm van een ‘Definition of Ready’ ingericht worden, om te waarborgen dat informatie beschikbaar zal zijn op het moment werkzaamheden op een sprint gepland worden. Voor een voorbeeld zoals een Audit backlog ingericht zou kunnen worden, zie appendix B.

De functionele en niet functionele requirements worden gespecifieerd in verschillende taken of ‘User stories’ (Schwaber & Sutherland, 2016). Van elke ‘User story’ is duidelijk wie de

verantwoordelijkheid heeft, welke werkzaamheden verricht moeten worden, en hoe dit bijdraagt aan de kwaliteit van het oordeel. Het gros van de ‘User stories’ omvat het beoordelen van de opzet, bestaan en werking van controle maatregelen die relevante risico’s afdekken. Afhankelijk van de prioriteit van een specifieke ‘user story’ wordt deze op de sprint ‘back log’ geplaatst. Op de sprint ‘back log’ staan alle audit werkzaamheden die gedurende de desbetreffende sprint uitgevoerd en opgeleverd dienen te worden. De prioritering van ‘User stories’ zal afhankelijk zijn van de risico

32 inschatting en de mate van mitigeren van de relevante risico’s. Gezien het belang van de risico inschattingen ten behoeve van de prioritering en de kwaliteit van het oordeel dient deze in voldoende mate gedocumenteerd te worden in het dossier of als onderdeel van de rapportage meegenomen te worden. Een specifieke ‘User story’ zal hier aan gewijd dienen te worden welke elke sprint op de ‘sprint backlog’ zal moeten staan. Voor een voorbeeld risk assessment en voorbeeld generieke user story, zie appendix C en Appendix D.

Teneinde een oordeel aan het eind van elke sprint te kunnen rapporteren moet er worden voldaan aan de standaarden voor interne audit. Het is derhalve van belang dat elke ‘user story’ voldoet aan minimale acceptatie criteria alvorens deze als gereed beschouwd kan worden. Deze acceptatie criteria worden in agile terminologie ‘Definition of Done’ genoemd. Elke ‘User story’ moet voldoen aan de ‘Definition of Done’ zodat de betrouwbaarheid en de relevantie van het oordeel

gewaarborgd blijven. Feitelijk betekent dit dat voor elke ‘User story’ in bepaalde mate

werkzaamheden uit de planning, veldwerk en rapportage fase verricht moeten worden. Afhankelijk van de werkzaamheden zullen de volgende hoofdonderwerpen in de ‘Definition of Done’ moet zijn opgenomen:

1. Scope is bepaald en ligt in lijn met de Audit risicobeoordeling; 2. Beoordeling van opzet en bestaan van de controle maatregelen; 3. Evalueren van de werking van de controle maatregelen;

4. Werkzaamheden zijn gedocumenteerd in lijn met de audit richtlijnen en gereviewed door een tweede auditor;

5. Bevindingen zijn uitgeschreven in rapportage vorm en audit oordeel is bijgewerkt; en, 6. Invloed op risico beoordeling en impact op ‘Product’ back log is bepaald en gedocumenteerd

en geaccordeerd door de product owner.

Met de implementatie van een generieke ‘Definition of Done’ wordt een bepaalde mate van kwaliteit nagestreefd. In appendix E, wordt per punt van de ‘Definition of Done’ ingegaan op de invloed op de kwaliteitsaspecten voor een audit.

Elke user story zal aan de generieke ‘Definition of Done’ voldoen waardoor betrokkenheid van de product owner en bij de uitvoering van werkzaamheden continue de relatie worden gezocht met de risk assessment op het niveau van de gehele audit. De betrouwbaarheid wordt eveneens door middel van de Definition of Done gewaarborgd doordat tijdige documentatie en tijdige review door een tweede auditor plaats moet vinden, voordat een ‘User story’ afgerond kan worden. Supervisie vindt derhalve plaats per User story gedurende de audit en niet meer aan het eind van de

33