Task breakdown binnen een Agile BI-project: 3 stappen als leidraad

Door: Jorg Vreeswijk

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.

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

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

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

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.

Task breakdown: binnen een Agile BI-project: 3 stappen als leidraad

Pg, 7

Wil je meer informatie? Neem dan een kijkje op ons blog.