Wil je weten hoe snel je scrumteam echt kan werken? Snelheid is een snelheidsmeter voor je agile project en biedt een ongeëvenaard inzicht in de werkcapaciteit van je team. Deze handleiding onthult de geheimen van snelheid in scrum, leert je hoe je die moet berekenen en laat zien hoe je deze krachtige statistiek kunt gebruiken om de toekomstige prestaties van je team te voorspellen.
Wat is snelheid in scrum?
In scrum en andere kaders voor Agile projectmanagement dient snelheid als een agile statistiek om het werk in te schatten dat een scrumteam binnen een bepaald tijdsbestek (meestal één sprint) kan voltooien.
Je kunt snelheid uitdrukken in storypoints, een maateenheid om de omvang van userstory's of taken met betrekking tot complexiteit, risico en onzekerheid te bepalen. Storypoints bieden een genuanceerdere manier om werk in te schatten dan op tijd gebaseerde statistieken, zoals uren of dagen.
Denk bijvoorbeeld aan een userstory voor het ontwikkelen van een inlogscherm voor de applicatie. Het team kan deze taak een storypointwaarde van 3 toewijzen op basis van de complexiteit en de inspanningen om de taak te voltooien. De integratie van een complexe betalingsgateway zou een waarde van 8 kunnen krijgen vanwege de grotere complexiteit en potentiële risico's.
Er zijn veel factoren die van invloed zijn op het aantal storypoints dat elk teamlid kan voltooien tijdens een sprint van twee weken, zoals de ervaring van de leden, de complexiteit van de taken en de werkdynamiek van het team. Nieuwe scrumteams hebben doorgaans gemiddeld 5-10 storypoints per persoon voor elke sprint van twee weken.
Inzicht in de snelheid van het team kan helpen om continu te verbeteren, zodat teams voorspellingen kunnen doen voor toekomstige sprints en realistische doelen kunnen plannen en stellen. Met deze statistiek kunnen teams een stabiel werkritme ontwikkelen, de tijdlijnen van projecten voorspellen en de verwachtingen van belanghebbenden beheren.
Snelheid in scrum berekenen
Meestal bereken je de snelheid aan het einde van elke sprint door de storypoints of andere maateenheden voor alle volledig voltooide userstory's bij elkaar op te tellen.
Hier is het stapsgewijze proces om snelheid in scrum te berekenen:
1. Plan een sprint
Voordat een sprint begint, moet je alle userstory's in de productbacklog op een rijtje zetten en er punten aan toewijzen. Bijvoorbeeld:
- Gebruikersauthenticatie toewijzen: 5 punten
- Integratie van betalingsgateway toevoegen: 8 punten
- Zoekfunctionaliteit implementeren: 3 punten
- Een gebruikersprofielpagina ontwikkelen: 13 punten
- E-mailmeldingen implementeren: 2 punten
- Databasequery's optimaliseren: 21 punten
- Een dashboard voor beheerders aanmaken: 5 punten
Het team moet zich inzetten om in de komende sprint userstory's in te vullen op basis van de gemiddelde snelheid van vorige sprints en andere factoren, zoals vakanties of externe afhankelijkheden. Als de gemiddelde snelheid bijvoorbeeld 15 punten is en er geen vakanties of externe afhankelijkheden zijn, kan het team zich inzetten voor userstory's van in totaal ongeveer 15 punten voor de volgende sprint.
2. Geef voltooide userstory's weer
Maak aan het einde van elke sprint een lijst aan van alle volledig voltooide userstory's. Dit moeten story's zijn die aan hun acceptatiecriteria hebben voldaan en die door de scrummaster en producteigenaar zijn goedgekeurd.
Als een userstory voor 90% klaar is, is dat nog geen volledig voltooid werk. Het team moet deze doorzetten naar de volgende sprint en de punten opnieuw evalueren op basis van de resterende taken.
3. Controleer punten
Het team had al storypoints moeten toekennen aan elke voltooide userstory. Als storypoints om welke reden dan ook opnieuw geëvalueerd moeten worden, dan is dit het moment om dat te doen.
Stel dat het team in de huidige sprint drie userstory's heeft voltooid: gebruikersauthenticatie toewijzen, integratie van betalingsgateway toevoegen en zoekfunctionaliteit implementeren. Je zou die taken kunnen toewijzen aan de hand van de volgende storypoints:
- Gebruikersauthenticatie toewijzen: 5 punten
- Integratie van betalingsgateway toevoegen: 8 punten
- Zoekfunctionaliteit implementeren: 3 punten
4. Tel de punten op om de snelheid te bepalen
Vervolgens moet je het aantal storypoints voor alle voltooide userstory's bij elkaar optellen. De som van de storypoints geeft de sprintsnelheid weer.
In het bovenstaande scenario is het totale aantal 5 punten + 8 punten + 3 punten = 16 punten. De snelheid voor deze sprint is dan 16 punten.
5. Bepaal gemiddelde snelheid
Je kunt een betrouwbaardere maatstaf voor toekomstige sprints verkrijgen door de gemiddelde snelheid te berekenen van het aantal sprints dat het team voltooit. Deze maatregel is vooral nuttig voor pasgevormde teams of teams die van grootte of structuur zijn veranderd.
Als de snelheden voor de laatste drie sprints bijvoorbeeld 14, 16 en 15 waren, dan is de gemiddelde snelheid (14 + 16 + 15)/3 = 15 punten.
Factoren die van invloed kunnen zijn op de scrumsnelheid
Er kunnen verschillende factoren van invloed zijn op de scrumstatistieken en -snelheid. Als je deze begrijpt, kan dat helpen bij het plannen en continu verbeteren van de prestaties van het team.
Teamgrootte en vaardigheidsniveau
Het aantal personen in een team en hun respectievelijke vaardigheidsniveaus kunnen van invloed zijn op het werk dat het team tijdens een sprint kan voltooien. Een groter team kan misschien meer storypoints behalen in een sprint. Meer mensen kunnen echter leiden tot hoge communicatiekosten en coördinatieproblemen.
Omgekeerd zou een klein, deskundig team beter kunnen presteren dan een groot, minder bekwaam team door complexe taken efficiënt uit te voeren.
Stabiliteit en ervaring van het team
Wanneer scrumteamleden gedurende meerdere sprints samenwerken, werken ze waarschijnlijk veel van de problemen weg die nieuwe teams belemmeren. Zij hebben vaste communicatiepatronen en weten wie waar goed in is.
Deze teams hebben gedeelde ervaringen waar ze gebruik van kunnen maken als er zich problemen voordoen. Deze vertrouwdheid kan de snelheid aanzienlijk verbeteren.
Complexiteit van userstory's
Een sprint vol complexe userstory's leidt meestal tot een lage snelheid. Het snelheidscijfer is misleidend als de complexiteit de toegewezen storypoints niet nauwkeurig weergeeft.
Om een constante snelheid te behouden, streven sommige teams naar een balans tussen taken met 'snelle resultaten' en complexere taken binnen een sprint.
Externe afhankelijkheden en beperkingen
Als je team afhankelijk is van een ander team om database-updates of API-integraties te voltooien en dat team te laat is, kan dat direct de snelheid van je team verlagen. Als je je bewust bent van deze afhankelijkheden en ze kunt plannen door middel van effectieve communicatie tussen teams, kun je de negatieve gevolgen voor de snelheid beperken.
Houd ook rekening met feestdagen of verplichte bedrijfsevenementen in de sprintplanning, aangezien die de beschikbare werktijd verkorten.
Snelheid gebruiken in scrum
Als je eenmaal begrijpt wat de snelheid van je team is, wordt deze een krachtig hulpmiddel voor verschillende onderdelen van sprintplanning en projectmanagement, zoals:
Toekomstige sprints inschatten
Als je weet wat de gemiddelde snelheid van je team is, voorkom je giswerk. Als je team in de afgelopen drie sprints een gemiddelde snelheid van 50 storypoints heeft behaald, heb je een basis op grond van gegevens om de volgende sprint te plannen. Als je volgende sprintbacklog ongeveer 50 storypoints bevat, dan doe je een redelijke toezegging.
De tijdlijnen van projecten voorspellen
Belanghebbenden vertrouwen meer op datagestuurde schattingen dan op veronderstellingen of wensen. Als je projectbacklog bijvoorbeeld 200 storypoints telt en de gemiddelde snelheid van het team 50 storypoints per sprint is, kun je met vrij veel zekerheid voorspellen dat het team waarschijnlijk nog ongeveer vier sprints nodig heeft om het project te voltooien.
Overmatige of een gebrek aan inzet identificeren
Als de snelheid van een team plotseling daalt naar 30 storypoints of omhoogschiet naar 70, is dat een signaal. Een constante daling kan betekenen dat het team zich overweldigd voelt, en een stijging kan betekenen dat teamleden te weinig worden uitgedaagd. Met deze kennis kun je in realtime aanpassingen maken, zoals het opnieuw toewijzen van taken of het heroverwegen van sprintdoelen.
Verbetering en iteratieve voortgang volgen
Door de snelheid in de loop van de tijd bij te houden, begrijp je of je team efficiënter wordt of dat aanhoudende problemen aandacht vereisen. Als je snelheid in verschillende sprints van 40 naar 60 stijgt, is dat een teken dat je procesverbeteringen resultaten opleveren.
Houd de snelheid bij in Jira
Jira biedt een snelheidsgrafiek, naast verschillende andere agile rapporten, zodat je softwareteam eenvoudig snelheden kan volgen, toekomstige prestaties kan voorspellen en sprintplanning eenvoudiger kan maken. Het is een alles-in-één tool om te visualiseren hoeveel werk je team aankan, zodat je in de toekomst nauwkeurigere sprintdoelen kunt stellen.
Bovendien biedt Jira ook functies voor agile statistieken, inzichten, rapportage en projectmanagement die je team nodig heeft om planning en prestaties naar een hoger niveau te tillen.
Snelheid in scrum: veelgestelde vragen
Is snelheid in scrum hetzelfde als productiviteit?
Nee, snelheid in scrum is niet hetzelfde als productiviteit. Snelheid is een statistiek die voornamelijk bedoeld is om te plannen en in te schatten hoeveel werk een team aankan in toekomstige sprints.
Productiviteit is meestal een bredere maatstaf die factoren zoals de kwaliteit van het werk, de efficiëntie van processen en de waarde voor het bedrijf kan omvatten.
Hoe kan een team de snelheid verhogen?
Teams kunnen de snelheid verhogen door regelmatig achteraf vergaderingen te houden om te bespreken wat goed en fout ging, en om verbeteringen aan te brengen voor de volgende sprint. Het minimaliseren van contextwisseling (het verminderen van regelmatige wisselen tussen verschillende taken of projecten), kan leiden tot een hogere en consistentere snelheid.
Wat zijn de beperkingen van het gebruik van snelheid in Scrum?
Hoewel snelheid een handige planningstool is, zijn er beperkingen aan verbonden en zou het niet de enige prestatiestatistiek moeten zijn om een team mee te evalueren. Voor een uitgebreider overzicht van de teamprestaties kun je overwegen om andere Agile-statistieken bij te houden.
Een belangrijke beperking is dat snelheid geen maatstaf is voor de kwaliteit van het werk of de geleverde bedrijfswaarde. Het is een kwantitatieve maatstaf die geen rekening houdt met de kwalitatieve aspecten van de complexiteit van een individuele userstory.
Snelheid is kenmerkend voor elk team. Het is geen maatstaf om de prestaties van verschillende teams met elkaar te vergelijken. Elke groep binnen een team werkt anders, waardoor er verschillende snelheden ontstaan. Een lagere algemene snelheid betekent niet automatisch dat het ene team minder succesvol is dan het andere.