Waarom heeft de Scrum Master statistieken en metrics nodig? Ten eerste om te controleren of zijn werkwijzen voor de voorspelbaarheid van resultaten en het verbeteren van de effectiviteit van het team effectief zijn. Maar ook om bij te houden hoe hun acties de Development Team beïnvloeden. Dat wil zeggen, hoe ze de gebruikerservaring van de medewerkers (UX) vormgeven. In dit artikel introduceren we de statistieken en metrics die de Scrum Master moet bijhouden.
De meest gebruikte statistieken en metrics die de Scrum Master moet bijhouden, zijn die welke het tempo en de stroom van taakuitvoering beschrijven. Dit zijn de Burnup Chart, de Burnup Chart en de Cumulative Flow Chart. Deze meten zowel de productontwikkeling als de effectiviteit van het team. Elk stelt je in staat om deze kwesties vanuit een ander perspectief te benaderen, dus het is een goed idee om ze samen te tonen. Ze zijn handige tools om de voortgang op verschillende schalen te beoordelen, zowel tijdens een Sprint als gedurende het hele productontwikkelingsproces.
De burndown chart toont de Scrum Master en het Development Team hoeveel werk er is gedaan en hoeveel er nog te doen is. De X-as toont de tijd die nog resteert om het werk te voltooien. De Y-as toont de hoeveelheid werk die nog gedaan moet worden en die was gepland in de Sprint Backlog of Product Backlog.
Deze chart helpt ook om de snelheid van het Development Team te bepalen, waar we ook een apart artikel aan zullen wijden. Hier zullen we alleen vermelden dat het een gemiddelde hoeveelheid werk is die tijdens één Sprint is gedaan.
Deze eenvoudige tool stelt de Scrum Master in staat om niet alleen te zien hoe efficiënt het team werkt. Het helpt ook om vragen te beantwoorden:
Bij het gebruik van de Burndown Chart moet de Scrum Master in gedachten houden dat het niet de enige tool is om de voortgang van het team statistisch te beoordelen. Het werkt het beste voor projecten waarbij de scope van het werk vast en bekend is. Het presteert niet goed bij het creëren van zeer innovatieve oplossingen met een nieuwe Klant. Dan kan de hoeveelheid werk die in het hele project moet worden gedaan – dat wil zeggen de inhoud van de Product Backlog – aanzienlijk veranderen tijdens het project, waardoor het moeilijk wordt om de Burndown Chart te gebruiken.
De Burnup Chart is het tegenovergestelde van de hierboven besproken Burndown chart. Ook hier toont de Y-as de hoeveelheid werk die nog moet worden gedaan. De X-as toont daarentegen de voltooiingstijd, uitgedrukt in het aantal Sprints of in data.
Echter, de Scrum Master gebruikt de Burnup Chart voor een iets ander doel. Dit komt omdat het je niet alleen helpt om de voortgang van het product en de voortgang van het Team te meten. Deze metric beoordeelt ook hoe de scope van het werk in een project in de loop van de tijd verandert. Daarom werkt het goed voor projecten met een variabele scope.
De Burnup Chart is ook een planningsinstrument dat in de loop van de tijd effectiever wordt. Het geeft antwoorden op de vraag hoeveel werk het Development Team naar schatting in de volgende Sprint zal doen.
Het derde type diagram dat zeer vruchtbaar is in het werk van de Scrum Master met het Development Team is het Cumulative Flow Diagram. Het biedt de analyse van hoe stabiel het tempo en de productiviteit van het Development Team zijn. De indeling van de assen is dezelfde als die van de Burnup Chart, dus het wordt vaak aangeduid als de meer complexe versie ervan.
Echter, het Cumulative Flow Diagram is niet alleen bedoeld om het aantal taken dat in een bepaalde periode is voltooid te bepalen. Het houdt ook rekening met het aantal taken dat in de wachtrij staat voor uitvoering. Dankzij dit maakt het mogelijk om de zogenaamde “knelpunten” te diagnosticeren – momenten in het proces die de creatie van een product vertragen.
Deze zeer diagnostische functie maakt het tot een van de meest nuttige metrics in handen van de Scrum Master. Dit komt omdat het mogelijk maakt om het werk te reorganiseren op een manier die de kracht van het Development Team anders verdeelt en stilstand voorkomt.
Regelmatig en nauwgezet onderhoud en analyse van statistieken is een essentieel onderdeel van het effectieve werk van een Scrum Master. Echter, hij/zij moet eerst rekening houden met de gebruikerservaring van de medewerkers van de developers, dat wil zeggen, de manier waarop zij het werk in het Scrum Team waarnemen. Het is echter niet de kwaliteit van de metrics die bepalend is, maar de manier waarop de Scrum Master ze gebruikt.
Als de statistieken worden bijgehouden in overeenstemming met de principes van Scrum – ze zijn transparant, openbaar en begrijpelijk voor de betrokken Developers – kunnen ze een manier zijn om het team te motiveren om efficiënter te werken of om hen te belonen voor geweldige resultaten. Echter, statistieken kunnen functioneren als een drukmiddel op het Development Team. Dan worden hun aanwijzingen een generator van beschuldigingen en wrok. Ze kunnen bijdragen aan het verslechteren van de teamgeest en het bederven van samenwerkingspraktijken.
De tweede belangrijke factor van de gebruikerservaring van Developers, waar de Scrum Master die met statistische tools werkt voor moet zorgen, is de manier van tijdbeheer. Dit komt omdat de Scrum Master voldoende tijd moet hebben om voor het Development Team te zorgen. Om deze reden is het, in het geval van een groot project, de moeite waard om te overwegen een extra persoon in het Scrum Team op te nemen. Hij/zij zal fungeren als projectmanager en zal voor de metrics zorgen. Hierdoor zal het de Scrum Master – en tot op zekere hoogte de Product Owner – ontlasten van de taken die hem/haar afleiden van het werken met het Development Team.
De Scrum Master moet de basisstatistieken bijhouden die het werk van het Development Team beschrijven. Hun vaardige interpretatie vergroot de kans om snel problemen in het werk van het Team op te sporen en daarop te reageren. Echter, belangrijker dan het bijhouden van de grafieken is wat de Scrum Master ermee doet. Ze moeten de metrics niet beschouwen als een hulpmiddel om het Team te evalueren, maar eerder als een nuttige hulp bij het motiveren van het Team en het diagnosticeren van hun eigen manier van werken. Dit komt omdat metrics alleen nuttige tools zullen zijn als ze helpen de processen van het Team en de Productverbetering te vergemakkelijken.
Als je onze inhoud leuk vindt, sluit je dan aan bij onze drukke bijengemeenschap op Facebook, Twitter, LinkedIn, Instagram, YouTube.
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 haar vermogen om onder tijdsdruk te werken, maken haar de beste persoon om ingewikkelde projecten werkelijkheid te laten worden.
Bedrijven worstelen met het beheren van een enorme hoeveelheid inhoud die online wordt gepubliceerd, van…
In het tijdperk van digitale transformatie hebben bedrijven toegang tot een ongekende hoeveelheid gegevens over…
Wist je dat je de essentie van een meeruurs opname van een vergadering of gesprek…
Stel je een wereld voor waarin jouw bedrijf boeiende, gepersonaliseerde video's kan maken voor elke…
Om het potentieel van grote taalmodellen (LLM's) volledig te benutten, moeten bedrijven een effectieve aanpak…
In 2018 was Unilever al begonnen aan een bewuste reis om automatisering en augmentatie in…