Samenvatting: Agile statistieken bieden inzicht in productiviteit via de verschillende stadia van een levenscyclus van softwareontwikkeling. Dit helpt om de kwaliteit van een product te beoordelen en de prestaties van het team bij te houden.
Statistieken zijn een gevoelig onderwerp.
Aan de ene kant hebben we allemaal wel eens een project meegemaakt waarbij geen gegevens van welke aard dan ook werden bijgehouden, en was het daarbij moeilijk te zeggen of we op schema lagen voor release of efficiënter werden naarmate we verder gingen. Aan de andere kant hebben velen van ons het ongeluk gehad om deel te nemen aan projecten waarbij statistieken als wapen werden gebruikt, waarbij het ene team tegen het andere werd uitgespeeld of verplicht weekendwerk werd gerechtvaardigd. Het is dus geen verrassing dat de meeste teams een haat-liefdeverhouding hebben met statistieken.
Maar dat hoeft niet zo te zijn. Het bijhouden en delen van agile statistieken kan verwarring verminderen en een licht werpen op de voortgang (en tegenslagen) van het team gedurende de ontwikkelingscyclus. Zo werkt dit.
Ken je bedrijf
'Gereed' vertelt maar de helft van het verhaal. Het gaat erom het juiste product te bouwen, op het juiste moment, voor de juiste markt. Op schema blijven gedurende het hele programma betekent het verzamelen en analyseren van relevante gegevens tijdens het hele traject. In elk agile programma is het belangrijk om zowel zakelijke statistieken als agile statistieken bij te houden. Zakelijke statistieken zijn gericht op de vraag of de oplossing voldoet aan de marktbehoefte, en agile statistieken meten aspecten van het ontwikkelingsproces.
"De zakelijke statistieken van een programma moeten geworteld zijn in de roadmap."
Neem voor elk initiatief op de roadmap verschillende belangrijke prestatie-indicatoren (KPI's) op die overeenkomen met de doelstellingen van het programma. Voeg daarnaast succescriteria toe voor elke productvereiste , zoals het acceptatiepercentage door eindgebruikers of het percentage code dat door geautomatiseerde tests wordt gedekt. Deze succescriteria worden gevoed in de agile statistieken van het programma. En hoe meer teams leren, hoe beter ze zich kunnen aanpassen en evolueren.
Agile KPI-statistieken gebruiken om je levering te optimaliseren
Sprintburndown
Scrum-teams organiseren ontwikkeling in sprints met tijdvakken. Aan het begin van de sprint voorspelt het team hoeveel werk ze kunnen voltooien tijdens een sprint. Een sprintburndown-rapport houdt vervolgens de voltooiing van het werk bij tijdens de sprint. De x-as staat voor tijd en de y-as verwijst naar de hoeveelheid werk die nog moet worden voltooid, gemeten in storypoints of uren. Het doel is om al het voorspelde werk aan het einde van de sprint te hebben voltooid.
Een team dat consequent aan de prognoses voldoet, is een aantrekkelijke reclame voor agile binnen de organisatie. Maar laat dat je niet verleiden om de cijfers te verdoezelen door een item compleet te verklaren voordat het dat echt is. Dan ziet alles er op korte termijn misschien goed uit, maar op de lange termijn belemmert dit het leren en verbeteren.
Lees hier meer over hoe je burndown-grafieken moet gebruiken in Jira
- Het team voltooit sprint na sprint vroegtijdig omdat ze niet genoeg werk aannemen.
- Het team mist de ene voorspellingssprint na de andere omdat ze zich inzetten voor te veel werk.
- De burndown-lijn daalt scherp in plaats van meer geleidelijk omdat het werk niet is opgesplitst in granulaire onderdelen.
- De producteigenaar voegt halverwege de sprint de scope toe of wijzigt deze.
Epic en release-burndown
Epic en release (of versie)-burndowngrafieken volgen de voortgang van de ontwikkeling over een grotere hoeveelheid werk dan de sprintburndown en begeleiden ontwikkeling voor zowel scrum- als kanban-teams. Aangezien een sprint (voor scrumteams) werk uit verschillende epics en versies kan bevatten, is het belangrijk om zowel de voortgang van individuele sprints als epics en versies bij te houden.
'Scope creep' is de injectie van meer vereisten in een eerder gedefinieerd project. Als het team bijvoorbeeld een nieuwe website voor het bedrijf levert, zou scope-creep om nieuwe functies vragen nadat de oorspronkelijke vereisten zijn geschetst. Hoewel het tolereren van scope-creep tijdens een sprint een slechte praktijk is, is verandering van scope binnen epics en versies een natuurlijk gevolg van agile ontwikkeling. Terwijl het team door het project gaat, kan de producteigenaar besluiten om werk aan te nemen of te verwijderen op basis van wat hij leert. De epic en release-burndowngrafieken houden iedereen op de hoogte van het komen en gaan van werk binnen de epic en versie.
- Epic- of releasevoorspellingen worden niet bijgewerkt terwijl het team het werk doet.
- Er wordt geen vooruitgang geboekt over een periode van verschillende iteraties.
- Chronische scope-creep, wat een teken kan zijn dat de producteigenaar het probleem dat het werk probeert op te lossen, niet volledig begrijpt.
- Scope groeit sneller dan het team het kan absorberen.
- Het team verzendt geen incrementele releases tijdens de ontwikkeling van een epic.
Snelheid
Snelheid is de gemiddelde hoeveelheid werk die een scrumteam tijdens een sprint voltooit, gemeten in storypoints of uren, en is erg handig voor prognoses. De producteigenaar kan snelheid gebruiken om te voorspellen hoe snel een team door de backlog heen kan werken, omdat het rapport het voorspelde en voltooide werk over verschillende iteraties bijhoudt: hoe meer iteraties, hoe nauwkeuriger de voorspelling.
Stel dat de producteigenaar 500 storypoints in de backlog wil voltooien. We weten dat het ontwikkelingsteam over het algemeen 50 storypoints per iteratie voltooit. De producteigenaar kan redelijkerwijs aannemen dat het team bij benadering 10 iteraties nodig heeft om het vereiste werk te voltooien.
Het is belangrijk om te controleren hoe de snelheid zich in de loop van de tijd ontwikkelt. Nieuwe teams kunnen een toename van de snelheid verwachten naarmate het team relaties en het werkproces optimaliseert. Bestaande teams kunnen hun snelheid volgen om consistente prestaties in de loop van de tijd te garanderen, en kunnen nagaan of een bepaalde proceswijziging tot verbeteringen heeft geleid of niet. Een afname van de gemiddelde snelheid is meestal een teken dat een deel van het ontwikkelingsproces van het team inefficiënt is geworden en bij het volgende retrospectief ter sprake moet worden gebracht.
Wanneer snelheid gedurende een lange periode grillig is, bekijk dan altijd de schattingspraktijken van het team opnieuw. Stel tijdens het retrospectief van het team de volgende vragen:
- Zijn er onvoorziene ontwikkelingsuitdagingen waarmee we geen rekening hebben gehouden bij het schatten van dit werk? Hoe kunnen we het werk beter uitsplitsen om enkele van deze uitdagingen aan het licht te brengen?
- Is er externe bedrijfsdruk die het team buiten zijn grenzen duwt? Lijdt naleving van best practices voor ontwikkeling er daardoor onder?
- Zijn we als team overijverig in het voorspellen van de sprint?
De snelheid van elk team is uniek. Als team A een snelheid van 50 heeft en team B een snelheid van 75 heeft, betekent dit niet dat team B een hogere doorvoer heeft. Omdat de schattingscultuur van elk team uniek is, is de snelheid dat ook. Weersta de verleiding om snelheid tussen teams te vergelijken. Meet het niveau van inspanning en output van werk op basis van de unieke interpretatie van storypoints door elk team.
Beheerschema
Beheerschema's richten zich op de cyclustijd van individuele issues: de totale tijd van 'in uitvoering' tot 'voltooid'. Teams met kortere cyclustijden hebben waarschijnlijk een hogere doorvoer, en teams met consistente cyclustijden voor veel issues zijn voorspelbaarder in het leveren van werk. Hoewel cyclustijd een primaire statistiek is voor kanban-teams, kunnen scrumteams ook profiteren van een geoptimaliseerde cyclustijd.
Het meten van cyclustijd is een efficiënte en flexibele manier om de processen van een team te verbeteren, omdat de resultaten van veranderingen vrijwel onmiddellijk waarneembaar zijn, waardoor ze meteen verdere aanpassingen kunnen aanbrengen. Het einddoel is om een consistente, korte cyclustijd te hebben, ongeacht het soort werk (nieuwe functie, technische schulden enz.).
Beheerschema's kunnen in het begin grillig lijken. Wees niet bezorgd over elke uitschieter. Zoek naar trends. Hier zijn twee gebieden om op te letten:
- Cyclustijd verlengen: het verlengen van de cyclustijd vermindert de zwaar bevochten agility van het team. Neem in het retrospectief van het team de tijd om een verlenging te begrijpen. Een uitzondering: als de definitie van 'gedaan' door het team is uitgebreid, is de cyclustijd waarschijnlijk ook uitgebreid.
- Grillige cyclustijd: Het doel is om een consistente cyclustijd te hebben voor werkitems met vergelijkbare storypointwaarden. Filter het beheerschema voor elke storypointwaarde om te controleren op consistentie. Als cyclustijd grillig is op kleine en grote storypointwaarden, besteed in het retrospectief dan tijd om de missers te onderzoeken en toekomstige schattingen te verbeteren.
Cumulatief stromingsschema
Het cumulatief stroomdiagram moet er van links naar rechts vloeiend uitzien. Bubbels of gaten in een willekeurige kleur duiden op tekorten en knelpunten, dus als je er een ziet, zoek dan naar manieren om kleurbanden over de diagram glad te strijken.
- Blokkerende issues zorgen voor grote reserves in sommige delen van het proces en tekorten in andere.
- Ongecontroleerde groei van de backlog in de loop van de tijd. Dit komt doordat producteigenaren geen issues afsluiten die verouderd zijn of gewoon een te lage prioriteit hebben om ooit te worden binnengehaald.
Nog meer statistieken
Goede statistieken zijn niet beperkt tot de hierboven besproken rapporten. Kwaliteit is bijvoorbeeld een belangrijke statistiek voor agile teams en er zijn een aantal traditionele statistieken die kunnen worden toegepast op agile ontwikkeling:
- Hoe veel defecten zijn er gevonden?
- tijdens de ontwikkeling?
- na release aan klanten?
- door mensen buiten het team?
- Hoeveel defecten worden uitgesteld tot een toekomstige release?
- Hoe veel verzoeken om klantondersteuning komen er binnen?
- Wat is het percentage geautomatiseerde testdekking?
Agile teams moeten ook kijken naar de releasefrequentie en leveringssnelheid. Aan het einde van elke sprint moet het team een softwarerelease uitbrengen voor productie. Hoe vaak gebeurt dat eigenlijk? Worden de meeste release-builds verzonden? In dezelfde geest: hoe lang duurt het voordat het team een release met een noodoplossing voor productie uitbrengt? Is release gemakkelijk voor het team of vereist het grote inspanningen?
Ontdek inzichten in context
Inzichten zijn een geweldig hulpmiddel voor teams om toegang te krijgen tot statistieken wanneer ze die nodig hebben: tijdens sprintplanning, inchecken bij de dagelijkse stand-up of het optimaliseren van de levering. Je kunt inzichten vinden in de rechterbovenhoek van het bord, de backlog en de implementatieweergave van Jira.
Inzichten geven een visuele momentopname van de volgende statistieken:
- Voortgang van sprint
- Analyse issuetype
- Sprinttoezegging
- Implementatiefrequentie
- Cyclustijd
Gebruik deze statistieken om teamprestaties continu te optimaliseren. Meer informatie over inzichten.
Conclusie...
Agile statistieken en KPI’s zijn slechts één onderdeel van het opbouwen van een teamcultuur. Ze geven kwantitatief inzicht in de prestaties van het team en leveren meetbare doelen voor het team. Hoewel ze belangrijk zijn, dien je er niet geobsedeerd mee te raken. Luisteren naar de feedback van het team tijdens retrospectieven is even belangrijk voor het vergroten van het vertrouwen in het hele team, de kwaliteit van het product en de ontwikkelingssnelheid tijdens het releaseproces. Gebruik zowel kwantitatieve als kwalitatieve feedback om verandering te stimuleren.
