Scrum Gids | 11. Statistieken en metrics die de Scrum Master moet bijhouden

Waarom heeft de Scrum Master statistieken en metrics nodig? Ten eerste om te controleren of zijn werkwijzen met betrekking tot 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 statistieken en metrics die de Scrum Master zou moeten bijhouden.

Statistieken en metrics belangrijk voor de Scrum Master – inhoudsopgave:

1. Het meten van de resultaten van het werk van het Development Team
2. Het monitoren van de gebruikerservaring van medewerkers Developers
3. Samenvatting

Het meten van de resultaten van het werk van het Development Team

De meest gebruikte statistieken en metrics die de Scrum Master zou moeten 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 maatregelen beoordelen zowel productontwikkeling als teameffectiviteit. 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.

Burndown Chart

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:

• Wat is er al van het werk voltooid?
• Hoeveel taken moeten er nog worden voltooid?
• Hoe lang zal het duren om het Product te ontwikkelen?

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.

Burnup chart

De Burnup Chart is het tegenovergestelde van de hierboven besproken Burndown chart. Ook hier toont de Y-as de hoeveelheid werk die nog gedaan moet worden. 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.

Cumulative Flow Diagram

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 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.

Het monitoren van de gebruikerservaring van medewerkers Developers

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. 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. Dankzij dit 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.

Statistieken en metrics – samenvatting

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 zouden de metrics niet moeten beschouwen als een instrument 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 bijencommunity op Facebook, Twitter, LinkedIn, Instagram, YouTube.