Scrum Gids | 32. Voordelen en nadelen van de Burndown Chart

De Burndown Chart heeft veel voordelen. Het is een van de belangrijkste meetinstrumenten in Scrum om verschillende redenen. Het is gemakkelijk te maken, te schalen en te lezen. Het heeft echter ook nadelen die het geen universeel hulpmiddel maken. In het artikel van vandaag behandelen we het onderwerp van de nadelen en voordelen van de Burndown Chart.

Voordelen en nadelen van de Burndown Chart – inhoudsopgave:

1. Inleiding
2. Voordelen van de Burndown Chart
3. Nadelen van de Burndown Chart
4. Samenvatting

Inleiding

We hebben in eerdere artikelen geschreven over wat het is, hoe je een Burndown Chart maakt en interpreteert. Vandaag zullen we ons richten op de voordelen en nadelen van de Burndown Chart. De meeste van deze nadelen zijn echter niet verborgen in de eenvoudige grafiek zelf. Ze zijn eerder gerelateerd aan de manieren waarop de Burndown Chart wordt gebruikt om het Development Team te motiveren, omdat ze de resultaten van hun werk beschrijven en zelforganisatie versterken.

Voordelen van de Burndown Chart

De Burndown Chart stelt je in staat om de voortgang van je project te visualiseren. De leesbaarheid en eenvoud maken het zo populair. Daarom is het een goed idee dat de Burndown Chart niet alleen een voortdurend bijgewerkte maatstaf is die verborgen is in een digitaal projectmanagementhulpmiddel. Als het mogelijk is, is het de moeite waard om het een referentiepunt voor het Development Team te maken dat zichtbaar is op de fysieke werkplek. Of het nu in de vorm van een on-screen visualisatie of een handgetekende schets is.

Het motiveert het Development Team

De transparantie van de Burndown Chart kan het een hulpmiddel maken om het Development Team te motiveren om efficiënt te werken. Het bereiken van het “nul” punt in elke Sprint kan een ambitieus doel van het Team worden, waarvoor beloningen worden gegeven – volgens de principes van zakelijke gamificatie.

De zichtbaarheid van een actuele en interessant onderhouden Burndown Chart kan ook de samenwerking en zelforganisatie bevorderen. Immers, de maatstaf is een maat voor teamwork. Het toont niet precies wie de geplande taken heeft voltooid – of niet – alleen de behaalde resultaten.

Het meet het daadwerkelijke werk dat is uitgevoerd

Ontwikkelaars beslissen hoeveel taken ze in een bepaalde Sprint zullen uitvoeren. Hoe ervaren het Team is, hoe nauwkeuriger ze hun acties moeten voorspellen. En de burndown chart weerspiegelt de werkelijke voortgang van de Sprint.

Daarom is het voordeel van de Burndown Chart niet zozeer het meten van de objectieve hoeveelheid werk die is gedaan, maar de verhouding van geplande naar voltooide taken. Zo leren ontwikkelaars geleidelijk hoe ze deze kunnen plannen en kunnen ze hun capaciteiten steeds nauwkeuriger inschatten en repetitieve fouten elimineren.

Het koppelt aan andere tools

Een van de significante voordelen van de Burndown Chart betreft zijn veelzijdigheid in combinatie met andere tools. De volgende tools kunnen van toepassing zijn op:

• het analyseren van het werk van het Development Team
• het visualiseren van de voortgang van het werk aan het Product
• het schatten van het projectbudget

Bijvoorbeeld, in het laatste geval maakt het gebruik van de Project Scale Burndown Chart een vergelijking van het geplande en werkelijke budget voor het hele project mogelijk.

Nadelen van de Burndown Chart

Ondanks alle hierboven beschreven voordelen van de Burndown Chart, kan het een bron van verwarring worden voor het Development Team. Wat we vaak de “gebreken” van de Burndown Chart noemen, zijn echter niet te wijten aan imperfecties van het hulpmiddel zelf. De problemen die hieronder worden beschreven, hebben betrekking op de manier van implementatie van de Burndown Chart in plaats van het ontwerp ervan. Hieronder staan de gebreken die het moeilijk kunnen maken om de voortgang van het Development Team op deze manier weer te geven.

“De menselijke factor”

Grafieken kunnen geen absolute maatstaf zijn voor de voortgang van een team. Het zijn gewoon hulpmiddelen die op verschillende, meer of minder vaardige manieren kunnen worden toegepast. We kunnen dit beschouwen als een nadeel (of voordeel) niet alleen van de Burndown Chart, maar ook van andere maatstaven voor team prestaties.

Om een Burndown Chart te maken, heb je andere mensen nodig om gegevens in te voeren. Met andere woorden, de ontwikkelaars noteren de tijd die nodig is om taken te voltooien op de grafiek. Ze hebben het misschien een beetje verlengd of verkort – hetzij door onoplettendheid of omdat ze het beter willen maken voor het team. Ontwikkelaars vergeten ook soms hun tijd te registreren. Of laten de timer aanstaan. Dit zorgt ervoor dat de werktijd zich uitstrekt tot enkele uren. En na het ontdekken van de fout is het moeilijk om de werkelijke gang van zaken te reconstrueren.

Wijzigingen in de Sprint Backlog

De Sprint Backlog mag niet worden gewijzigd na de start van een Sprint. In de praktijk komen dergelijke wijzigingen echter vrij vaak voor. Ze zijn het gevolg van veranderende eisen van belanghebbenden. Of onvoorziene problemen waarmee ontwikkelaars worden geconfronteerd.

Dit zorgt ervoor dat de Burndown Chart wordt geschaald. Dit komt omdat de tijd die nodig is om de taken te voltooien hetzelfde blijft. Echter, de schaal van de resterende taken neemt toe. Dit kan een misleidende indruk geven dat het Development Team het werk dat in een bepaalde Sprint moet worden gedaan, verkeerd heeft gepland. Of dat het te langzaam werkt.

Wijzigingen in de Sprint Backlog kunnen ook het gevolg zijn van taken die te snel voor voltooiing waren ingepland. In een dergelijke situatie besluit het Development Team meestal om het aantal taken te verhogen. Dit kan op zijn beurt resulteren in het niet op tijd voltooien ervan. Ook kunnen conflicten ontstaan door de overlap van resterende taken uit de vorige Sprint met nieuwe taken die moeten worden voltooid door belanghebbenden en producteigenaren.

Wijzigingen in de Product Backlog

Grote wijzigingen in de Product Backlog kunnen de vorm van de Burndown Chart verstoren. En zo het beeld van de voortgang van het werk en de effectiviteit van het Team sterk vervalsen. Dit gebeurt wanneer nieuwe User Stories verschijnen. En die welke dicht bij de implementatiefase staan, worden vaak in kleinere delen opgesplitst. Het komt ook voor dat de Klant afziet van bepaalde Productfunctionaliteiten.

Daarom moet men bij het interpreteren van de Burndown Chart worden geleid door kennis en ervaring in het evalueren van de prestaties van het Team. En ook rekening houden met de variabiliteit van de Backlog. Als de grafiek niet de enige maatstaf is die wordt gebruikt om prestaties te evalueren, zullen de andere grafieken een completer beeld van de voortgang van het werk geven.

Samenvatting

De Burndown Chart kan aanzienlijk bijdragen aan de motivatie van het Development Team. Dit komt omdat het een maatstaf biedt voor het werk dat daadwerkelijk op het plan is gedaan. Bovendien kan de combinatie met andere meetinstrumenten een bron van waardevolle kennis zijn over het werk van het Team en de planning van het Product.

Door de Scrum-principes zorgvuldig toe te passen, kun je potentiële problemen met de Burndown Chart vermijden. Het belangrijkste is om de hulpmiddelen voor het bijhouden van de grafiek aan te passen aan het werk van het Scrum Team, evenals om wijzigingen in de Sprint en Product Backlog te minimaliseren, waar we meer over schrijven in dit artikel.

Als je onze inhoud leuk vindt, sluit je dan aan bij onze drukke bijengemeenschap op Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.