Scrum Gids | 34. Snelheid in Scrum – Snelheid van het Ontwikkelteam

Snelheid in Scrum helpt je om de snelheid te bepalen waarmee het Scrum Team taken voltooit. We kunnen het definiëren als het gemiddelde aantal Story Points dat in één Sprint is voltooid. Snelheid kan ook de duur van een project schatten op basis van de al voltooide werkvoortgang. Dit heeft echter alleen zin voor een volwassen team dat op een gelijkmatige en constante snelheid werkt. Kijk eens naar wat Snelheid is en hoe je het het beste voor jou kunt laten werken!

Snelheid in Scrum – inhoudsopgave:

1. Snelheid in Scrum – Inleiding
2. Werkelijke en geplande snelheid
3. Moeilijkheden en risico’s verbonden aan Snelheid in Scrum
4. Samenvatting

Snelheid in Scrum – Inleiding

Snelheid is een optionele maar populaire methode om het tempo van een Scrum Team te meten. Dit komt omdat een nauwkeurig geschatte Snelheid het mogelijk maakt om, tot op zekere hoogte, de tijd te voorspellen die nodig is om een project te voltooien. Het is echter een maatstaf die alleen kan worden toegepast op een bepaald Ontwikkelteam, dat taken zal uitvoeren die het zelf heeft “gewaardeerd” met behulp van een bekende eenheid, zoals Story Points, bijvoorbeeld.

De Snelheid van het Ontwikkelteam wordt meestal gepresenteerd in de vorm van een Snelheid Grafiek. Op de X-as zijn opeenvolgende Sprints gemarkeerd. Op de Y-as vinden we daarentegen het aantal Story Points of andere overeenkomstige eenheden die in een bepaalde Sprint zijn voltooid. Met de Snelheid Grafiek krijgt het Scrum Team een duidelijk overzicht van veranderingen in het tempo van zijn werk. Als de lijn die op de grafiek is gemarkeerd stijgt, betekent dit dat het Team zijn efficiëntie optimaliseert of de waarde van Story Points verlaagt. Zowel de Scrum Master als de Product Owner moeten daarom de lijn die de Snelheid van het Team toont, zorgvuldig volgen.

Werkelijke en geplande snelheid

De werkelijke Snelheid van het Ontwikkelteam beschrijft het werktempo in de voltooide Sprint en wordt aan het einde van elke Sprint berekend. Het neemt de waarde aan van de som van Story Points voor alle voltooide User Stories. De werkelijke Snelheid van het Ontwikkelteam stelt je in staat om met enige waarschijnlijkheid het tempo van toekomstige taken te plannen en te schatten.

De geplande Snelheid, daarentegen, wordt geschat op basis van een gemiddelde waarde van de werkelijke Snelheid. Het vereist de aanname van geen verandering in het Ontwikkelteam. Het is een belangrijk intern hulpmiddel voor het Ontwikkelteam, dat op basis daarvan kan beoordelen of de samenwerking in het Team goed verloopt en of het werktempo wordt gehandhaafd.

Geplande Snelheid stelt ook de Product Owner in staat om de uitvoeringstijd van goed gedefinieerde User Stories die zijn gepland voor uitvoering in de volgende Sprints te voorspellen. Dit maakt efficiënter onderhoud van de Product Backlog mogelijk, waar we in dit artikel over hebben geschreven. De praktijk van het toepassen van geplande Snelheid om projectduur te schatten is echter niet zo eenvoudig.

Moeilijkheden en risico’s verbonden aan Snelheid in Scrum

Snelheid in Scrum krijgt vaak te veel belang zonder rekening te houden met de volgende factoren:

• het schatten van grotere geheel of het gehele project – terwijl het Ontwikkelteam nauwkeurig het aantal Story Points kan schatten dat aan een specifieke taak moet worden toegewezen, is het zeer moeilijk of onmogelijk om grotere geheel voor toekomstige implementatie in deze eenheden te beschrijven
• veranderingen in het project – elke verandering in het project betekent potentieel een verandering in het aantal Story Points dat nodig is om het Productdoel te bereiken. Het kan ook zijn dat al voltooide taken moeten worden aangepast of zelfs niet worden gebruikt in de definitieve versie van het Product
• onvoorziene gebeurtenissen – het voorspellen van het tempo van toekomstige projecten op basis van die al voltooide, dat wil zeggen, het vertalen van werkelijke Snelheid naar Geplande Snelheid, kan resulteren in nauwkeurige schattingen. Echter, elk project heeft zijn eigen bijzonderheden en een nauwkeurige voorspelling op basis van de geschiedenis is meestal onmogelijk.

Samenvatting

Het gebruik van Snelheid als een maatstaf om de effectiviteit van het Ontwikkelteam te evalueren kan leiden tot een afname van de betrouwbaarheid. Het kan ook de kwaliteit van de schattingen verminderen, waar we in meer detail over hebben geschreven in dit artikel. Tenslotte kan het Ontwikkelteam om de best mogelijke resultaten in de metrics te behalen, de arbeidsintensiteit van taken overschatten om de Snelheid te verhogen. Dit is nadelig omdat het team zelf dan waardevolle informatie verliest om verbeteringen aan te brengen en zijn taken nauwkeuriger te plannen.

Snelheid in Scrum is vooral handig als een interne maatstaf die door het Ontwikkelteam wordt gebruikt om het tempo van zijn werk te evalueren. Dit komt omdat het het in staat stelt te bepalen hoeveel taken het in staat is om tijdens een enkele Sprint te voltooien.

Snelheid in handen van de Product Owner wordt een nuttig hulpmiddel voor het schatten van de deadline voor grotere taken.

Echter, de grootste risico’s zijn verbonden aan het gebruik van Snelheid als een maatstaf voor het evalueren van het Ontwikkelteam. Dit komt omdat het kan leiden tot een verlaging van de geloofwaardigheid en zelfs een opzettelijke overschatting van zijn waarde om de externe evaluatie van het werk van het Scrum Team te verbeteren.

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