In dit artikel ligt de focus op de defect metrics. Dit zijn metrics die heel simpel meten hoe vaak iets fout is gegaan. Ik behandel 2 varianten: Defect Count by Story en de Defect Count by Sprint. In het Nederlands: de fouttelling per story en de foutmeting per sprint.
Ik wilde beginnen met het uitleggen van de meest waardevolle van deze twee metrics: defect Story by Sprint, maar ik realiseerde mij dat je de fouttelling per Sprint dan wel juist moet toepassen. Dus eerst een korte toelichting op de ‘fouttelling per Sprint’.
Fouttelling per Sprint (Defect count by Sprint)
Een heel simpele metric. Deze metric telt de fouten (defects) die in een Sprint ontstaan. Als je deze metric sporadisch doet, is het als metric een niet zo interessant gegeven. Je hebt deze metric echter nodig voor de onderstaande metric.
Hoe werkt het?
Je berekent deze metric correct als je elke fout of defect die voorkomt tijdens deze Sprint één keer telt.
Als dezelfde fout twee keer in dezelfde Sprint voorkomt, dan tel je hem nog steeds één keer. Vanzelfsprekend is twee keer dezelfde fout nou niet een toonbeeld van een goede werkwijze en zou je daar als team wat aan kunnen doen. Voor deze telling is dit echter niet belangrijk.
Defects count by Sprint
Het is slechts een telling van het aantal gemaakt defects. Idealiter staat deze op nul, zo niet dan zie je graag dat deze omlaag gaat richting de nul.
Hoewel het puur een cijfer is uit een meting per Sprint is het raadzaam om deze in een reeks te plaatsen en de ontwikkeling in de tijd, dus een aantal Sprints te volgen. Een enkele meting met hoge score kan een incident zijn, maar als er sprake is van een patroon dan zou het team dit patroon kunnen bespreken in een Retrospective.
Een tekortkoming van de fouttelling per Sprint metric is dat het bijvoorbeeld geen rekening houdt met het aantal opgenomen User Stories. 5 fouten op 30 User Stories zegt wellicht wat anders dan 5 fouten op 10 opgenomen User Stories. Daarnaast zijn er best veel verschillen in de ruime context mogelijk: zoals oplopende technical debt, teamgrootte en teamervaring etc. Zie daarvoor de laatste paragraaf in dit artikel.
Aantal defects t.o.v. User Stories
Dit is een verhoudingscijfer die tot stand komt door het aantal defecten in de Sprint te delen door het totaal aantal User Stories opgenomen in de sprint. De formule is dus:
aantal defecten / opgenomen User Stories
Bovenstaande is een simpele rekensom, maar er zijn aandachtspunten! Aan het einde van de Sprint tel je het aantal opgenomen Stories, zowel de openstaande en afgeronde Stories, vergeet dus niet de Stories mee te tellen die het defect hebben en wellicht nog niet zijn afgerond! Het tweede aandachtspunt is dat je defects die uit eerdere sprints komen en nu afgerond zijn niet mag meetellen. Anders krijg je dubbeltellingen.
Dit is dus een verhoudingscijfer welk iets meer zegt dan alleen het aantal. Ook dit cijfer komt het best tot zijn recht in een reeks.
Wil je deze metrics wel gebruiken?
Het zijn gemakkelijk te gebruiken Defect metrics en daar zit direct ook een gevaar in.
Het is achterliggende idee van deze metrics is dat het tellen van fouten een maatstaf is van kwaliteit. Dat kan natuurlijk kloppen, maar er zijn altijd heel veel variabelen die mee tellen. Het aantal redenen voor meer defects deze Sprint is vrijwel oneindig.
De vraag die je kunt stellen is: helpen het bijhouden van deze metrics je echt bij het verhogen van het succes. Zo niet, dan is het waste en die tijd kan je beter besteden aan belangrijker werk. Het kan ook een waardevolle meting zijn om het gesprek te starten.
Het uitgangspunt van Agile software ontwikkeling is namelijk nog steeds om fouten direct ter herstellen, PUNT! Fouten dient een team direct te bespreken en de waarom vraag zou dan gesteld kunnen worden. Het is continuous improvement.
Meer lezen over Agile metrics?