Dit artikel gaat over handvatten bij de ‘task breakdown’ van SCRUM-stories, om zo de voorspelbaarheid van het Agile-BI team te bevorderen.

1. Task breakdown binnen
een Agile BI-project: 3
stappen als leidraad
Door: Jorg Vreeswijk

2. Task breakdown: binnen een Agile BI-project: 3 stappen als leidraad
Pg, 2
Dit artikel is onderdeel van de themareeks BI & Techniek, bedoeld om de meer technische
aspecten van BI voor het voetlicht te krijgen. Het is geschreven voor project-managers en
ontwikkelaars binnen de BI, die zich afvragen hoe agile zich in de BI-praktijk staande houdt.
Succesvolle, ervaren teams hebben geen probleem met het uitvoeren van hun ‘task breakdown’.
Veel startende teams hebben hier echter wel moeite mee en dat is niet zo raar. Zoals zo vaak in
‘agile werken’, is het ook hier weer de kunst om de juiste balans te vinden. Zeker in BI hebben
we wel eens de neiging om eeuwig te discussiëren en te veel vooraf te willen doen en uit te
willen pluizen. Op die manier zijn we stiekem ouderwets aan het watervallen, leveren we heel
lang geen waarde op en stoppen we potentieel veel moeite in zaken die we wellicht nooit gaan
uitvoeren. Aan de andere kant schieten we soms door, doen we zo goed als niets vooraf en
worden we onvoorspelbaar. Hoewel het per situatie verschilt, zie ik binnen BI en
datawarehousing de volgende drie stappen doorgaans als een goede leidraad bij de ‘task
breakdown’. De aanpak die ik hier beschrijf vloeit uit eerdere eigen ervaringen binnen
verschillende Agile BI-projecten.

3. Task breakdown: binnen een Agile BI-project: 3 stappen als leidraad
Pg, 3
Stap 1: Maak taken klein genoeg voor een goede inschatting
Maar wat is een goede inschatting? Dat hangt van veel factoren af en eigenlijk voornamelijk van
de vraag in hoeverre een team mag falen. Of misschien beter gezegd…, hoe goed is een team in
het falen met beperkte schade (non-deadly failure). Het gaat te ver voor dit blog om hier dieper
op in te gaan, maar laten we stellen dat het een goed teken is als het team over het algemeen
oplevert wat het heeft beloofd. Met andere woorden; het team is voorspelbaar.
Teams worden voorspelbaar door onder andere het ‘refinen’ van de opdrachten (stories) en het
gebruik van planning-poker voor de inschattingen. Refinement van de stories op de backlog
moet een constante activiteit van het team zijn. Tijdens het refinen en inschatten praten de
teamleden vaak al over bepaalde ‘hoog-over’ taken, en dat is nu precies van belang in deze
stap. Deze taken – of misschien in dit vroege stadium de ‘hoog-over stappen’ – hebben
teamleden nodig om de opdracht goed te begrijpen en voor zich te zien. Het is voor teams heel
natuurlijk om hier al over te praten en te discussiëren. Of voor sommige opdrachten zelfs al een
standaardlijstje te maken. Het is vaak alleen nog maar zaak om dit geordend terug te laten

4. Task breakdown: binnen een Agile BI-project: 3 stappen als leidraad
Pg, 4
komen in de refinement sessie. En als we ze dan toch bespreken: noteer die ‘hoog-over’ taken
gelijk even in de story.
Stap 2: Maak taken klein genoeg voor een goede planning
De volgende stap vindt plaats als we de sprint willen starten, dus op zijn laatst in sprintplanning
deel twee. Het belangrijkste daarbij is dat we, als team, een goed overzicht krijgen van hoe we
de sprint gaan inrichten. In deze stap willen we de taken zo opsplitsen dat we een goed gevoel
krijgen van de doorlooptijd van de verschillende taken en inzichtelijk krijgen welke taken
afhankelijkheden laten zien. Snappen we wat de globale aanpak wordt? Past het in de sprint?
Wat betekent het als iemand er niet is? En moeten we toch eerst een taak onderaan het
scrumbord oppakken zodat we later in de sprint niet vastlopen?
Stap 3: Maak taken klein genoeg voor een goede team-communicatie
De laatste stap richt zich op de samenwerking binnen het team. Hoe gaan de taken het team
ondersteunen in het elkaar helpen en het onderling snappen waar iedereen mee bezig is? Wat
we in deze stap doen is taken klein genoeg maken zodat iedereen snapt wat de taak precies

5. Task breakdown: binnen een Agile BI-project: 3 stappen als leidraad
Pg, 5
inhoudt en andere teamleden eventueel kunnen bijspringen. Hierbij kijken we zeker verder dan
een functioneel blokje. We gaan dus van ‘bouw X’ naar: ‘schrijf test a’, ‘schrijf test b’, ‘maak
tabel a’, ‘maak tabel b’, ‘maak ETL a’, ‘maak ETL b’, ‘voer test a uit’ etc. Het doel hiervan is dat
teamleden gedurende de sprint eenvoudig van elkaar begrijpen waar ze mee bezig zijn
(geweest), elkaar kunnen helpen en bij kunnen springen.
Hierbij is het handig te proberen om taken (een stuk) kleiner dan acht uur te maken. Zo zorgen
we ervoor dat een taak eigenlijk niet langer dan één stand-up in ‘busy’ kan blijven hangen. Dit
bevordert niet alleen de communicatie, maar zorgt er ook voor dat mogelijke ‘impediments’ snel
naar boven komen. Stap 3 begint eigenlijk al bij sprintplanning deel twee (en heeft dus wat
overlap met stap 2) en loopt de gehele sprint door. Als een teamlid voor het oppakken doorheeft
dat één van zijn taken prima uiteen kan vallen in kleinere taken, dan zal hij deze verder op
moeten splitsen.
Aan de slag!
Het zal van team tot team verschillen hoe en wanneer taken worden opgesplitst. Het lijkt
misschien evident, maar door ook hierin discipline aan te brengen en standaard deze drie

6. Task breakdown: binnen een Agile BI-project: 3 stappen als leidraad
Pg, 6
stappen aan te houden zullen teams uiteindelijk meer voorspelbaar zijn en onderling beter
kunnen communiceren.
Dit blogartikel is geschreven door Jorg Vreeswijk.

7. Task breakdown: binnen een Agile BI-project: 3 stappen als leidraad
Pg, 7
Wil je meer informatie? Neem dan een kijkje op ons blog.