Categories: BlogScrum Gids

Scrum Gids | 31. Hoe maak je een Burndown Chart en hoe interpreteer je deze?

Een Burndown Chart is relatief eenvoudig te maken. Er zijn veel tools beschikbaar om het te genereren op basis van het werk dat is geregistreerd door leden van het Ontwikkelteam. Ondanks de eenvoud kan de interpretatie waardevolle informatie bieden voor het hele Scrum Team. Lees dit artikel om te ontdekken hoe je een Burndown Chart kunt maken en interpreteren.

Hoe maak je een Burndown Chart en hoe interpreteer je het? – inhoudsopgave:

  1. Hoe maak je een Burndown Chart?
  2. Wie is verantwoordelijk voor de Burndown Chart?
  3. Hoe interpreteer je een Burndown Chart?
  4. Echte en ideale Burndown Chart
  5. Selecteren van de meeteenheid
  6. Samenvatting

Hoe maak je een Burndown Chart?

Het Ontwikkelteam moet zijn dagelijkse werk monitoren. Dit is de basis, niet alleen voor het evalueren van de effectiviteit, maar ook voor het verbeteren ervan. En een van de eenvoudigste en bewezen tools voor dit doel is de Burndown Chart.

Je kunt het handmatig maken door een coördinatensysteem op een stuk papier te tekenen. Op de Y-as moet je de hoeveelheid werk plotten, uitgedrukt in een gekozen eenheid, bijvoorbeeld story points. Op de X-as teken je een schaal die de opeenvolgende dagen van de Sprint aangeeft. Teken een lijn van de ideale sprint en markeer vervolgens het aantal realistisch voltooide taken voor elke dag. Hoewel deze oplossing charmant is en het team betrekt, is het niet erg praktisch. Het is ook niet noodzakelijk geschikt voor remote teams.

Daarom zijn digitale middelen voor het maken van een Burndown Chart veel gebruikelijker. Veel tools voor het registreren van werk aan taken die zijn verdeeld onder Teamleden hebben een optie om automatisch een Burndown Chart te maken. Dan hoeft een Ontwikkelaar alleen maar het begin en het einde van het werk aan een bepaalde productfunctie te markeren, en hun bijdrage wordt weerspiegeld in de Burndown Chart.

Met de juiste tools is het ook mogelijk om de grafiek vrij te schalen. Dit geeft inzicht in de verbranding, niet alleen op het niveau van een gegeven Sprint, maar ook op de schaal van een kwartaal of het hele project.

Een belangrijke factor om te overwegen bij het kiezen van een tool voor het maken van een Burndown Chart is de toegankelijkheid voor alle Scrum Teamleden. De zichtbaarheid van de Burndown Chart voor het hele Ontwikkelteam is een belangrijke motivatiefactor. Even belangrijk is een dagelijkse blik op de lijn die het resterende werk toont. Praten over burn-in tijdens de Daily Scrum, laat Ontwikkelaars nadenken over de manieren waarop ze werken en de huidige staat van het Product.

Wie is verantwoordelijk voor de Burndown Chart?

De vraag van eigendom van de Burndown Chart is enigszins controversieel. Aan de ene kant zou het toebehoren aan de Scrum Master, omdat het een tool is om ervoor te zorgen dat het Team efficiënt en volgens plan werkt. Aan de andere kant zou het in handen van de Product Owner moeten blijven, omdat het de voortgang naar een Productdoel weerspiegelt dat aan de Klant wordt gecommuniceerd. Bovendien is er een derde partij die aanspraak kan maken op het eigendom, namelijk het Ontwikkelteam, aangezien de grafiek fungeert als een intern hulpmiddel.

De Burndown Chart is een essentiële maatstaf om de effectiviteit van het Ontwikkelteam te evalueren en wordt door alle Scrum Teamleden geaccepteerd. Daarom zijn transparantie en toegankelijkheid cruciaal. Echter, het doel ervan is om het Team te dienen. Het is bedoeld om de zelforganisatie te versterken, de motivatie te verbeteren en een reëel beeld te geven van de status van het werk aan de aan hem toegewezen taken. Daarom kan in theorie elk lid van het Ontwikkelteam de Burndown Chart bijwerken.

In de praktijk valt de taak van het bijwerken van de Burndown Chart meestal toe aan de Scrum Master. Dit gebeurt vooral aan het begin van zijn werk met een nieuw Ontwikkelteam wanneer de Team Velocity nog variabel en moeilijk te schatten is. Niettemin wordt aanbevolen deze taak te delegeren aan een van de Ontwikkelaars. Tenslotte is de grafiek bedoeld als een eerlijke en interne meting van de voortgang van het werk zoals beoordeeld door de Ontwikkelaars zelf.

Hoe interpreteer je een Burndown Chart?

We hebben het uiterlijk van de Burndown Chart in detail beschreven in een vorig artikel. Hier willen we je alleen herinneren aan het feit dat de X-as de tijd toont die nog resteert om het werk te voltooien. Aan de andere kant toont de Y-as de hoeveelheid werk die nog moet worden gedaan.

Echte en ideale Burndown Chart

Om een Burndown Chart te interpreteren, is de sleutel niet alleen de regelmatige plotting van de echte “verbranding”, dat wil zeggen de uitvoering van taken door het Ontwikkelteam. Even belangrijk voor het beeld is de vergelijking met de ideale verbrandingslijn (richtlijn).

Door de ideale verbrandingslijn te vergelijken met de werkelijke afname van werk die op de Burndown Chart is gemarkeerd, kunnen twee zeer belangrijke parameters worden beoordeeld. Ten eerste, om te zien of het werk doorgaat met het huidige tempo, zal het Ontwikkelteam het Sprintdoel of Productdoel op tijd halen. Ten tweede, om een idee te krijgen van wanneer het werk zal zijn voltooid terwijl het huidige tempo wordt gehandhaafd. Met andere woorden, de Burndown Chart toont het werkelijke tempo van de taken, en de ideale lijn toont met welk tempo het Team zou moeten werken om de taken te voltooien.

De Burndown Chart maakt het ook mogelijk om een waarde te bepalen die de Development Team Velocity op lange termijn wordt genoemd. We zullen hier een apart artikel aan wijden. Hier willen we alleen vermelden dat het een waarde is die wordt bepaald door de hoeveelheid werk die tijdens één Sprint is gedaan.

Dankzij het feit dat de Burndown Chart de vergelijking van een ideale verbrandingslijn met een werkelijke afname van het aantal taken illustreert, maakt het mogelijk om het werktempo te schatten. En zo het risico van projectvertragingen te anticiperen.

Selecteren van de meeteenheid

Team velocity wordt meestal gemeten in eenheden die story points. Het definieert het aantal user stories dat is gerealiseerd. Deze kunnen zeer verschillende hoeveelheden werk vereisen.

Daarom gebruiken veel Scrum Teams een tijdgebaseerde maat. Afhankelijk van de schaal zijn dit dagen of manuren. Elke Ontwikkelaar schat en registreert vervolgens de hoeveelheid tijd die aan hun taken is besteed.

Een andere optie is om taken als eenheid aan te nemen. Dit zijn iets grotere eenheden, die op hun beurt een waarde krijgen die is uitgedrukt in story points, of in dagen of manuren. Het is een eenheid die de klant in staat stelt om de voortgang van het werk aan het product op een duidelijkere manier te presenteren.

Ongeacht de meeteenheid is het de moeite waard om het principe van het berekenen van de snelheid van het Ontwikkelteam te onthouden. In een gegeven dag of Sprint tellen alleen taken die daadwerkelijk zijn voltooid. Dit betekent dat taken die zijn gestart, worden geteld voor de volgende dag of Sprint, zelfs als alleen de laatste test nog ontbreekt.

Samenvatting

Met de beschikbare teammonitoringtools wordt het maken van een Burndown Chart een gemakkelijke taak. De belangrijkste kwestie is om de samenhang, duidelijkheid en toegankelijkheid voor alle Scrum Teamleden te waarborgen.

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

Caroline Becker

Als projectmanager is Caroline een expert in het vinden van nieuwe methoden om de beste workflows te ontwerpen en processen te optimaliseren. Haar organisatorische vaardigheden en het vermogen om onder tijdsdruk te werken, maken haar de beste persoon om ingewikkelde projecten werkelijkheid te laten worden.

View all posts →

Caroline Becker

Als projectmanager is Caroline een expert in het vinden van nieuwe methoden om de beste workflows te ontwerpen en processen te optimaliseren. Haar organisatorische vaardigheden en het vermogen om onder tijdsdruk te werken, maken haar de beste persoon om ingewikkelde projecten werkelijkheid te laten worden.

Share
Published by
Caroline Becker

Recent Posts

De kracht van AI in muziekcreatie verkennen | AI in business #33

Als het gaat om AI in muziekproductie, is het het beste in co-creatie, en vooral…

54 minutes ago

Scrum Gids | 12. Samenwerking tussen Product Owner en Scrum Master

In het artikel van vandaag zullen we het onderwerp van samenwerking tussen de Product Owner…

2 hours ago

Waarom zijn zelfbewustzijn en zelfregulatie belangrijk in leiderschap?

Elke leider heeft doelen zoals het opbouwen van een team dat op gepaste wijze hoge…

4 hours ago

3 e-mailmarketingplatforms

Social media-advertentiecampagnes, direct contact tijdens branche-evenementen, het aanbieden van educatieve materialen om kennis en bewustzijn…

6 hours ago

Scrum Gids | 28. Sprint in Scrum

Verschillende kleinere evenementen vormen een Sprint in Scrum. Sprints vormen op hun beurt samen een…

8 hours ago

Hoe meer klanten naar uw bedrijf te trekken met videomarketing?

Ontvangers grijpen steeds vaker naar videomateriaal. Geschreven vormen worden minder populair. Traditionele bloggers proberen zich…

10 hours ago