Vijf agile KPI-statistieken waar je blij van wordt

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.

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

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.

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

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.

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.

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

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.

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?