Twee metrics die behoren bij Agile Project Tools: Recidive en first time pass rate. Wederom zijn deze metrics voor de ‘diehards’. De beschrijving van deze metrics is interessant als je al de nodige meters in agile werken heb gemaakt. Het geeft je meer inzichten.
Recidive / recidivism
Recidive is een interessante metric. Dit is de verhouding van User Stories die na opname in de Sprint terugkeert naar de Sprint Backlog. Kortom, opgepakt als compleet inzichtelijk, maar alsnog teruggelegd.
Het is een metric die aangeeft hoevaak voltooide User Stories voor de tweede keer een Sprint in gaan. Dit is meestal het gevolg van het falen van een of andere QA-test. Hoewel dit ook om andere redenen kan zijn, misschien zijn vereisten veranderd of iets dergelijks. De uitdaging is natuurlijk om echt te weten waardoor dit veroorzaakt wordt.
Je kunt het als volgt berekenen. Neem het totale aantal voltooide User Stories in een Sprint die voor de tweede keer in ontwikkeling is gegaan. Deel deze vervolgens te delen door het totale aantal voltooide User Stories.
Als één User Story meer dan eens in ontwikkeling is gegaan, tel het dan één keer. Vanzelfsprekend is dat geen goed teken. Je zal naar de reden moeten vragen, maar het mag geen invloed hebben op de berekening.
Eigenlijk wil je geen recidive krijgen, het percentage is idealiter 0%. Maar fouten maken mag, moet zelfs binnen agile werken. Als je maar van fouten leert. Als het recidive cijfer hoger is dan 10% of 20%, is dat reden tot grote bezorgdheid.
Het duidt waarschijnlijk op een kwaliteitsprobleem, maar ga niet raden. Het kan bijvoorbeeld de kwaliteit van de code zijn, kwaliteit van de eisen of testkwaliteit of zelfs de omgeving. Ga niet alleen of rechtstreeks naar de ontwikkelaar. Trek het breder en begin met het stellen van vragen en probeer de oorzaak te achterhalen.
First-time pass rate
First-time pass rate of eerste slagingspercentage. In het Nederlands wordt deze metric niet zo vaak uitgesproken.
First-time pass rate is vergelijkbaar met recidive. Het is het percentage testcases dat de eerste keer dat ze worden uitgevoerd wordt behaald. Berekenen? Neem je het aantal testcases dat minstens één keer mislukt is en deel het door het totale aantal testcases.
Dit kan per sprint of per release zijn, elk kan als een afzonderlijke statistiek worden beschouwd. Deze meting wordt meestal gedaan voor voortgang van testcases te bepalen, dat wil zeggen nieuwe features.
Je kan deze metric ook gebruiken voor het meten van regressietests. Dit is het testen van oude functies om ervoor te zorgen dat ze niet falen. In tegenstelling tot wat men vaak doet, moet je de voortgangs- en regressiemetingen apart houden. De reden is omdat ze beiden een ander verhaal vertellen.
Het first-pass percentage zou bijna 100% moeten zijn. Zelfs voor teams zonder uitgebreide automatisering moet er een redelijk kwaliteitsniveau ingebouwd zijn. Als het lager is dan 90%, is er een kwaliteitsprobleem!
Net als bij recidive problemen kan je een antwoord zoeken. Zoek in het deel van het proces dat een oorzaak zou kunnen zijn van de problemen. Start niet met de mensen er op aan te spreken. Als je redelijke testautomatisering implementeert, moet bijna 100% gemakkelijk haalbaar zijn.
Als je geen testcases gebruikt, baseer je je op User Stories. Neem in dat geval het aantal voltooide User Stories dat een of meer tests heeft overgeslagen en deel ze door het aantal voltooide verhalen in die periode.
User Stories mogen alleen worden gebruikt voor voortgangstests, gebruik geen User Stories voor regressietests. User Stories vertegenwoordigen incrementeel werk om een increment tot stand te brengen. Ze zijn dus niet geschikt om het product opnieuw te testen.